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METHOD AND SYSTEM FOR FACILITATING FINANCIAL 
TRANSACTIONS BETWEEN CONSUMERS OVER THE 
INTERNET 



FIELD OF THE INVENTION 

The invention relates generally to computer-implemented financial 
transactions, and more particularly, relates to completing a transaction between 
two individual consumers by transferring money from one consumer to the 
other according to transaction instructions received online from the consumers. 

BACKGROUND OF THE INVENTION 

The Internet has become a popular place to conduct business. Through 
Web auction sites, Web sites for displaying classified ads, Web shopping malls, 
online chat rooms, and other online transaction facilitation sites, two consumers 
may agree to a transaction. Frequently, such transactions involve the exchange 
of goods or services for money. While consumers frequently find that agreeing 
to transactions on the Internet is easy, completing a payment to consummate the 
transaction is more difficult. 

Typically, two consumers who have agreed through the Internet to 
exchange goods for money resort to offline methods to perform the exchange. 
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For example, the seller may ship the goods to the buyer through a shipping 
service, and the buyer may send a paper check to the seller. 

Such offline methods of exchange are problematic. Because the buyer 
and the seller are usually strangers, they may not trust each other to perform 

5 their mutual obligations under the agreement. Accordingly, they may be 
unable to agree whether the buyer will send the check first or the seller will 
send the goods first. Even if the buyer and the seller agree that the seller will 
ship the goods at the same time as the buyer sends the check, the seller has no 
guarantee that the check will not bounce. Likewise, the buyer has no guarantee 

10 that the goods will arrive in satisfactory condition. Accordingly, a significant 
percentage of transactions to which an individual buyer and seller have agreed 
upon over the Internet are never consummated. 

Another inconvenience of transactions agreed upon by individuals over 
the Internet is that the buyer is often limited to paying by cash or paper check. 

15 More convenient payment instruments exist, such as credit cards and bank 
account debits through electronic fund transactions. However, the buyer 
typically does not have the option to use these other payment instruments when 
the seller is an individual as opposed to a retail business that has been pre- 
established as an online merchant. 

20 The term "merchant" is used herein to refer to a seller of goods or 

services who is authorized by a credit card association (such as DISCOVER, 
VISA, or MASTERCARD) to submit to the credit card association charges on 
credit cards belonging to members of the credit card association. After 
receiving an authorization for the charge, the merchant then receives from the 

25 credit card association a direct deposit into the merchant's bank account of the 
amount of the charge. As known to those skilled in the art, a business must 
undergo an approval process in order to become a merchant, and upon 
approval, the merchant is assigned a merchant number. 

Although retail businesses are routinely set up as merchants in order to 

30 accept payments through credit cards or electronic fund transactions, this is not 
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an adequate solution to facilitating payments between individuals over the 
Internet. For example, merchants, after undergoing an extensive underwriting 
effort, are typically given special privileges, such as a general authorization to 
charge credit cards. This general authorization provides the merchant with the 

5 ability to commit fraud. Specifically, the merchant is capable of charging a 
customer's credit card more than he should. Also, the merchant may submit 
charges on a credit card belonging to a credit card association member with 
which the merchant has never had any contact. For these reasons, the idea of 
allowing individual sellers to become merchants has heretofore been rejected. 

10 Another problem with an individual seller becoming a merchant is that 

the approval process for becoming a merchant is frequently more of a hassle 
than an occasional seller is willing to undergo. The purpose of the approval 
process is to reduce the risk of fraud by the merchant. Accordingly, the seller 
usually must submit extensive background information for consideration in the 

15 approval process. This may be inconvenient and time consuming for the seller. 

Therefore, there is a need in the art for a safe and convenient method by 
which one consumer can pay a second consumer over the Internet. 

SUMMARY OF THE INVENTION 

20 The present invention meets the needs described above in a computer- 

implemented service that enables two individual consumers to complete a 
transaction that includes payment from one consumer (the payor, or buyer) to 
another consumer (the payee, or seller). An intermediary typically operates the 
service over a computer network of nodes, such as the Internet. The buyer has 

25 the convenience of paying through a variety of different payment instruments. 
Likewise, the seller has the convenience of receiving payment through a variety 
of different disbursement instruments. 

For a fee, the intermediary collects the payment from the buyer and pays 
the seller. One advantage of a consumer-to-consumer payment process 

30 operated by an intermediary is that the risk of fraud by the seller is reduced 
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because the buyer need not provide information about his payment instrument 
to the seller. Rather, the intermediary maintains information about the buyer's 
payment instrument in secret. Similarly, the intermediary need not provide the 
seller with a general authorization to charge a payment instrument, such as a 
5 credit card. 

Because the intermediary collects payment from the buyer, the consumer- 
to-consumer payment process of the present invention also provides the 
advantage of not requiring the seller to register as a merchant. Rather, the 
seller simply registers a disbursement instrument for receiving payment from 

10 the intermediary. This disbursement instrument registration process may be 
simpler and more convenient than the process a retail business typically 
undergoes to register as a merchant. 

Although the intermediary may receive payment from the buyer before 
the intermediary transfers the payment to the seller, the intermediary may 

15 choose to pay the seller before receiving payment from the buyer. In this case, 
the intermediary assumes the risk of nonpayment by the buyer. 

Alternatively, the intermediary may pay a third party that specializes in 
processing transactions for the payment instrument chosen by the buyer to 
assume the risk of nonpayment by the buyer. In this case, the intermediary 

20 receives a promise of payment from the third party before the intermediary 
pays the seller. Such a promise of payment from the third party is referred to 
as an authorization. 

Generally described, the present invention comprises a method for 
providing a consumer-to-consumer payment service. A payment enabler, 

25 which can be a node of a computer network, receives registration of a payment 
instrument from a payor located at a first remote computer. The payment 
enabler also receives registration of a disbursement instrument from a payee 
located at a second remote computer. 
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Then, the payment enabler receives a command from the payor to pay the 
payee an amount of money that the payor owes the payee. The command may 
be the submission of the payor's registration for the payment instrument. 

In response to the command to pay the payee, the payment enabler 

5 obtains an authorization for a transfer of the amount of money from the payor 
through the payment instrument to a first intermediary bank account. The 
amount of money may actually be deposited in the first intermediary bank 
account at a later time. After obtaining the authorization, the payment enabler 
may order the transfer of the amount of money from a second intermediary 

10 bank, which may be the same account as the first intermediary bank account, 
through the disbursement instrument to the payee. This payment to the payee 
may occur after authorization, but before the payment from the payor has been 
deposited in the first intermediary bank account. Alternatively, the payment to 
the payee may occur after the payment from the payor has been deposited in the 

15 first intermediary bank account. 

The various aspects of the present invention may be more clearly 
understood and appreciated from a review of the following detailed description 
of the disclosed embodiments and by reference to the appended drawings and 
claims. 

20 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1A is a block diagram illustrating a typical scenario in which a 
consumer-to-consumer payment process would be beneficial. 

FIG. IB is a block diagram illustrating the transfer of money in a 
25 consumer-to-consumer payment process in accordance with an exemplary 
embodiment of the present invention. 

FIG. 2 is a block diagram illustrating a computer network architecture 
for enabling consumer-to-consumer payments in accordance with an exemplary 
embodiment of the present invention. 
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FIG. 3 is a flow chart illustrating the steps of a consumer-to-consumer 
process in accordance with an exemplary embodiment of the present invention. 

FIG. 4A is a flow chart illustrating a procedure for registration of a flash 
cash deposit as a payment instrument in accordance with an exemplary 
5 embodiment of the present invention. 

FIG. 4B is a flow chart illustrating a procedure for registration of credit 
card as a payment instrument in accordance with an exemplary embodiment of 
the present invention. 

FIG. 4C is a flow chart illustrating a procedure for registration of bank 
10 account as a payment instrument via electronic fund transactions in accordance 
with an exemplary embodiment of the present invention. 

FIG. 4D is a flow chart illustrating a procedure for registration of virtual 
private payment account as a payment instrument in accordance with an 
exemplary embodiment of the present invention. 
15 FIG. 4E is a flow chart illustrating a procedure for registration of a 

paper check as a payment instrument in accordance with an exemplary 
embodiment of the present invention. 

FIG. 5A is a flow chart illustrating a procedure for registration of bank 
account as a disbursement instrument via electronic fund transactions in 
20 accordance with an exemplary embodiment of the present invention. 

FIG. 5B is a flow chart illustrating a procedure for registration of a 
virtual private payment account as a disbursement instrument in accordance 
with an exemplary embodiment of the present invention. 

FIG. 5C is a flow chart illustrating a procedure for registration of a 
25 paper check as a disbursement instrument in accordance with an exemplary 
embodiment of the present invention. 

FIG. 6 is a flow chart illustrating steps the payment enabler can follow to 
complete the transaction between the buyer and the seller in accordance with an 
exemplary embodiment of the present invention. 
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FIG. 7 is a flow chart illustrating steps the payment enabler can follow to 
verify delivery of acceptable goods to the buyer in accordance with an 
exemplary embodiment of the present invention. 

FIG. 8 is a flow chart illustrating steps for refunding money to the buyer 
5 in accordance with an exemplary embodiment of the present invention. 

FIG. 9 is a flow chart illustrating the steps of an auction process that 
includes static registration of the buyer and the seller with the payment enabler 
in accordance with an exemplary embodiment of the present invention. 

FIG. 10 is a flow chart illustrating the steps of an auction process that 
10 includes dynamic registration of the buyer with the payment enabler in 
accordance with an exemplary embodiment of the present invention. 

FIG. 11 is a flow chart illustrating the steps of an auction process that 
includes dynamic registration of the seller with the payment enabler in 
accordance with an exemplary embodiment of the present invention. 
15 FIG. 12 is a flow chart illustrating the steps of an online cash register 

creation process in accordance with an exemplary embodiment of the present 
invention. 

FIG. 13 is a flow chart illustrating the steps of an online cash register 
payment process in accordance with an exemplary embodiment of the present 
20 invention. 

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS 

The present invention is typically embodied in a computer-implemented 
service that enables two individual consumers to complete a transaction that 

25 includes payment from one consumer (the payor, or buyer) to another 
consumer (the payee, or seller). An intermediary typically operates the service 
over a computer network of nodes, such as the Internet. The payor has the 
convenience of paying through a variety of different payment instruments. 
Likewise, the payee has the convenience of receiving payment through a variety 

30 of different disbursement instruments. 
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Optionally, the intermediary may hold the payment from the payor in 
escrow until some predetermined condition is fulfilled. Once that 
predetermined condition is fulfilled, the intermediary pays the payee. If, for 
example, the transaction between the buyer and seller is for the sale of goods, 

5 the intermediary may hold the payment in escrow until the seller has delivered 
acceptable goods to the buyer. While holding the money in trust during the 
escrow process, the intermediary may store the money in a bank account. 

To fully appreciate the present invention, one must understand the 
difference between a merchant and a consumer. The term "merchant" is used 

10 herein to refer to a seller of goods or services who is authorized by a credit 
card association (such as DISCOVER, VISA, or MASTERCARD) to submit to 
the credit card association charges on credit cards belonging to members of the 
credit card association. After receiving an authorization for the charge, the 
merchant then receives from the credit card association a direct deposit into the 

15 merchant's bank account of the amount of the charge. As known to those 
skilled in the art, the merchant's bank account must be pre-approved, and upon 
approval, the merchant is assigned a merchant number. 

A consumer, on the other hand, is defined as an individual who has not 
been registered as a merchant. The computer network of the present invention 

20 facilitates payments from a payor to a payee without requiring either consumer 
to be registered as a merchant. With the help of the figures, in which like 
numerals refer to like elements throughout the several figures, the detailed 
description now explains how the computer network accomplishes this. 

25 Overview of the Consumer-to-Consumer Payment Process 

FIG. 1A illustrates a typical scenario 100 A in which a consumer-to- 
consumer payment process would be beneficial. The scenario 100A depicts a 
payee (or seller) 130 and a payor (or buyer) 110. The seller 130 and the buyer 
110 have concluded an agreement over the Internet 160. Per this agreement, 

30 the seller 130 has promised to ship goods 150 to the buyer 110. In return, the 
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buyer 110 has promised to pay the seller 130 an amount of money (also called a 
payment) 140. The consumer-to-consumer payment process of the present 
invention provides a convenient solution for enabling the buyer 110 and the 
seller 130 to consummate the transaction to which they have agreed. 

5 FIG. IB provides an illustration 100B of the transfer of money in the 

consumer-to-consumer payment process. FIG. IB shows the payor (or buyer) 
110 and the payee (or seller) 130. An intermediary 120 facilitates the transfer 
of money 140 from the buyer 110 to the seller 130. The intermediary 120 is 
typically a business that operates the consumer-to-consumer payment service. 

10 Generally, the responsibilities of the intermediary 120 include collecting 

the payment 140 from the buyer 110 and paying the seller 130. For 
performing this service, the intermediary 120 typically charges a fee. The 
intermediary may collect this fee by paying the seller an amount equal to the 
buyer's payment to the intermediary minus the fee. 

15 Although the intermediary 120 may receive payment 140 from the buyer 

110 before the intermediary transfers the payment 140 to the seller 130, the 
intermediary may choose to pay the seller before receiving payment from the 
buyer. In this case, the intermediary 120 assumes the risk of nonpayment by 
the buyer 110. If the intermediary 120 has assumed the risk of nonpayment by 

20 the buyer 110 and the buyer does not pay in a timely manner, the intermediary 
may use the fees collected by offering the consumer to consumer payment 
service to either cover the loss or pursue collection from the buyer. 

Instead of assuming the risk of nonpayment in order to pay the seller 130 
before receiving payment 140 from the buyer 110, the intermediary 120 may 

25 pay a third party (not shown) that specializes in processing transactions for the 
payment instrument chosen by the buyer 110 to assume the risk of nonpayment 
by the buyer. In this case, the intermediary 120 chooses the third party 
processor for the third party's dependability in financial transactions, and the 
intermediary receives a promise of payment from the third party before the 
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intermediary pays the seller 130. Such a promise of payment from the third 
party is referred to as an "authorization." 

In the consumer to consumer payment process, the intermediary 120 
preferably permits the buyer 110 to pay the intermediary through any one of a 

5 variety of different financial instruments. As shown in FIG. IB, these financial 
instruments, called payment instruments, may include flash cash, a credit card, 
a bank account (which is debited through an electronic fund transaction), a 
virtual private payment account (which is debited through an electronic 
transaction), or a physical check. 

10 Preferably, the intermediary 120 permits the seller 130 to receive 

payment 140 from the intermediary through any one of a variety of financial 
instruments. As shown in FIG. IB, these financial instruments, called 
disbursement instruments, may include a bank account (which is credited 
through an electronic fund transaction), a virtual private payment account 

15 (which is credited through an electronic transaction), or a physical check. 
Some financial instruments can be both payment instruments and disbursement 
instruments. 

Credit cards, electronic fund transactions for bank accounts, and the 
handling of physical checks are well known to those skilled in the art. 
20 However, flash cash and virtual payment accounts are not familiar to typical 
readers. Accordingly, a general description of these two financial instruments 
is now provided. 

Flash cash is a payment instrument that enables a payor to execute 
payment orders over the Internet based on a prearranged cash deposit. To 
25 create the flash cash payment instrument, a payor first communicates over the 
Internet with a flash cash processor in order to prearrange the cash deposit. 
The payor then physically visits a location registered with the flash cash 
processor. At the registered location, the payor deposits cash. At a later time, 
the payor can instruct the flash cash processor over the Internet to pay the 
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deposited amount (or a lesser amount) to a payee. The payee's bank account is 
then automatically credited in an electronic fund transaction. 

There are many embodiments of a virtual private payment account. Each 
embodiment differs in the functionality provided by the virtual private payment 

5 account. Typically, a virtual private payment account is offered through an 
online retailer or an Internet service provider (ISP). The owner of the virtual 
private payment account may buy items, typically through online transactions, 
and charge them to the virtual private payment account. Because only entities 
closely associated with the entity offering the virtual private payment account 

10 will accept payment from the account, the entity accepting payment from the 
virtual private payment account is typically not charged a processing fee. In 
essence, the virtual private payment account is like a private label credit card, 
but no plastic card is issued to the owner of the account. 

When a virtual private payment account owner makes a purchase and 

15 charges the purchase to the account, the charge may be covered by a positive 
balance in the account. The virtual private payment account may also be 
associated with a line of credit, and purchases charged to the virtual private 
payment account which result in a negative balance may be billed to the account 
owner in periodic statements. 

20 Various options for permitting the creation of positive balances in virtual 

private payment accounts may exist at the discretion of the entity offering the 
account. For example, the entity offering the virtual private payment account 
may permit a cash deposit to create a positive virtual private payment account 
balance. Also, the entity offering the account may permit associated retailers to 

25 credit a virtual private payment account, possibly for promotional purposes. 

Optionally, the entity offering the virtual private payment account may 
allow the account owner to receive monetary disbursements equivalent to the 
positive account balance. In another embodiment, the entity offering the virtual 
private payment account may allow the account owner to receive monetary 

30 disbursements only for positive account balances created through refunds or 
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cash deposits, but not for positive account balances created by a retailer for 
promotional purposes. 

Computer Network for Enabling Consumer-to-Consumer Payments 

5 FIG. 2 is a block diagram illustrating an exemplary computer network 

architecture 200 for providing the consumer to consumer payment service. 
Each one of the various nodes 210, 220, 230, 240, 250, 270, 275, 280, 285, and 
290 performs functions in the consumer to consumer payment process that are 
different than the functions the other computer nodes perform. 

10 Each node of the network 200 may have typical features of a computer 

system, such as a processing unit, a system memory containing random access 
memory (RAM) and read only memory (ROM), and a system bus that couples 
the system memory to the processing unit. The computer may also include 
various memory storage devices, such as a hard disk drive, a magnetic disk 

15 drive (e.g., to read from or write to a removable magnetic disk), and an optical 
disk drive (e.g., to read from or write to optical media such as a CD-ROM). 

A number of program modules may be stored in the drives and RAM of 
the computer system. Program modules control how the computer system 
functions and interacts with the user, with input/output devices, or with other 

20 computers. Program modules include routines, an operating system, 
application program modules, data structures, browsers, and other software or 
firmware components. The invention may conveniently be implemented in 
various program modules that are stored on the computers of the network 200 
and implement the methods described in the detailed description. 

25 No particular programming language will be described for carrying out 

the various procedures described in the detailed description because it is 
considered that the operations, steps, and procedures described and illustrated 
in the accompanying drawings are sufficiently disclosed to permit one of 
ordinary skill in the art to practice an exemplary embodiment of the present 

30 invention. Moreover, there are many computers and operating systems which 
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may be used in practicing an exemplary embodiment, and therefore no detailed 
computer program could be provided which would be applicable to all of these 
many different systems. Each user of a particular computer will be aware of 
the language and tools which are most useful for that user's needs and purposes. 

5 Likewise, various computer nodes of the network 200 require one or 

more databases for storing information pertinent to that computer's role in 
consumer to consumer payment process. In the detailed description, these 
databases are frequently described with respect to their functionality or the 
types of information they store. One skilled in the art should recognize that a 

10 variety of different databases and a variety of different record structures for 
storing information in those databases are available for providing the described 
functionality or storing the described information. Accordingly, details of such 
database implementations need not be described. Where details of a database 
implementation are described, the detailed description provides them by way of 

15 example, not by way of limitation. 

In FIG. 2, the lines connecting the various nodes of the computer 
network 200 illustrate network communication connections. For example, 
these connections may be Internet connections. Instead, a given connection 
between two computers of the network 200 may be a dedicated connection 

20 intended to provide a high speed, special purpose communications link between 
the two computers. When a first computer node is described as remote to a 
second computer node, the first computer node and the second computer node 
are linked by a network communication connection. 

One skilled in the art will appreciate that the network practicing an 

25 embodiment of the present invention may take various forms. Accordingly, 
one may use other types of networks and combinations of network connections 
in a given embodiment of the present invention. 

Still referring to FIG. 2, the detailed description will describe the 
functionality of the various computer nodes of the computer network 200. The 

30 buyer 110 communicates with the computer network 200 through the buyer 
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computer 220. Likewise, the seller 130 communicates with the computer 
network 200 through the seller computer 210. Preferably, the buyer computer 
220 and the seller computer 210 are connected to the computer network 200 
through Internet connections. Using HyperText Transfer Protocol (HTTP), 

5 computer nodes 230 and 240 may communicate with the buyer 110 and the 
seller 130 through Web pages. To use these Web pages, the buyer computer 
220 and seller computer 210 typically run an appropriate Web browser. 

The described Web pages provide information to the buyer 110 and the 
seller 130 about the consumer to consumer payment service. Furthermore, 

10 these Web pages provide a convenient graphical user interface for receiving 
information from the buyer 110 and the seller 130. For example, forms, which 
are well known to those skilled in the art of Web design, provide an easy and 
efficient mechanism for soliciting and receiving information from the buyer 
110 and the seller 130 through Web pages. However, other communication 

15 protocols and other graphical user interfaces are known to those skilled in the 
art, and therefore these communication alternatives may be used for 
implementing the present invention. 

The transaction facilitator 230 may be a Web site that allows two people 
to define a desired transaction. Usually, the transaction facilitator 230 also 

20 serves to introduce the payor 110 and the payee 130. When the transaction is 
for the sale of goods, the payor 110 is referred to as a buyer, and the payee 130 
is referred to as a seller. 

A typical transaction facilitator 230 is an Internet auction site, such as 
EBAY and YAHOO! AUCTION. Generally, such auction sites 230 allow a 

25 seller 130 to post an item for sale to potential bidders. Bidders then place bids 
on the posted items, and the high bidder wins the auction, thereby becoming the 
buyer 110. 

Similarly, the transaction facilitator 230 may be an Internet classifieds 
site, which allows a seller 130 to post an item for sale at a specified price. The 
30 classifieds site 230 then forwards to the seller 130 all offers from potential 
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buyers to buy the item at the specified price. The seller 130 can then accept 
one of the offers to create a transaction. If implemented by the Internet 
classifieds site 230, a potential buyer may have the opportunity to negotiate the 
sale price of the item with the seller 130. 

5 Often, a transaction facilitator 230 requires users of the service offered 

by the transaction facilitator to register with the transaction facilitator. 
Typically, a user registers to use the transaction facilitator 230 by providing 
basic identification information, such as name, e-mail, and password. The 
transaction facilitator 230 may assign the person a unique user ID for keeping 

10 track of information pertaining to the user. The transaction facilitator 230 may 
use the user ID as a key to a database record storing the information identifying 
the user and his transactions. To log into the transaction facilitator 230, the 
user may need to provide the user ID and the appropriate password. 

Preferably, the transaction facilitator 230 also has a mechanism for 

15 storing information about specific transactions and the buyer 110 and the seller 
130 in those transactions. This may be done through a database of transaction 
records, each identified by a unique transaction ID and having fields for storing 
the buyer user ID, the seller user ID, the transaction amount, and the item. 

After the transaction facilitator 230 determines that the buyer 220 and the 

20 seller 210 have agreed upon a transaction, the transaction facilitator refers the 
transaction to the consumer to consumer payment enabler 240 to administer the 
consumer to consumer payment service. Typically, the intermediary 120 runs 
the payment enabler 240. The payment enabler 240 may offer an application 
programming interface providing transaction facilitators, such as the 

25 transaction facilitator 230, with a convenient and standardized means to 
communicate with the payment enabler. 

When referring a transaction to the payment enabler 240, the transaction 
facilitator 230 may automatically pass information about the buyer 110, the 
seller 130, and their underlying transaction to the payment enabler. The 

30 payment enabler 240 then uses this information to administer the consumer to 
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consumer payment process, thereby facilitating payment from the buyer 110 to 
the seller 130. By automatically passing transaction information from the 
transaction facilitator 230 to the payment enabler 240, the consumer to 
consumer payment service eliminates the need for the buyer 110 and the seller 
5 130 to provide duplicate information to the payment enabler 240 that the buyer 
and seller already provided to the transaction facilitator when defining their 
transaction. 

Preferably, the transaction facilitator 230 and the payment enabler 240 
cooperate to implement the consumer to consumer payment service in a manner 

10 that prevents the buyer 110 and the seller 130 from realizing that the 
transaction facilitation service provided by the transaction facilitator and the 
consumer to consumer payment service provided by the payment enabler are 
administered by two different computer nodes, possibly run by two different 
entities. For example, the transaction facilitator 230 preferably passes the 

15 transaction information to the payment enabler 240 without knowledge of the 
buyer 110 or the seller 130. 

When communicating with the buyer 110 and the seller 130 to administer 
the consumer to consumer payment process, the payment enabler 240 
preferably employs Web pages that are branded identically to the Web pages 

20 that the transaction facilitator 230 uses when communicating with the buyer and 
the seller. In other words, all Web pages provided to the buyer 110 and the 
seller 130 by the transaction facilitator 230 and the payment enabler 240 
preferably bear the same trademarks. Alternatively, these Web pages can be 
co-branded with the trademarks of both the entity running the transaction 

25 facilitator 230 and the entity running the payment enabler 240. 

Preferably, the payment enabler 240 delegates the responsibility for 
processing transactions for each type of financial instrument to a different 
computer node of the network. Specifically, the flash cash processor 285 
processes flash cash payments from the buyer 110, the credit card transaction 

30 processor 290 processes credit card payments from the buyer 110, the 
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electronic fund transaction processor 270 processes credits to and debits from 
bank accounts through electronic fund transactions, the virtual private payment 
account processor 275 processes credits to and debits from virtual private 
payment accounts, and the check processor 280 processes paper check payments 

5 from the buyer 110 and paper check disbursements to the seller 130. Each of 
the computer nodes 270, 275, 280, 285, and 290, in turn, may interact with 
other computer nodes (not shown) of the network 200 in order to process a 
payment from the buyer 110 or a disbursement to the seller 130. 

The computer nodes for processing disbursement instruments are called 

10 disbursement instrument processors 260. The computer nodes for processing 
payment instruments are called payment instrument processors 265. All the 
disbursement instrument processors 260 of the exemplary embodiment of FIG. 
2 are also payment instrument processors 265. 

Preferably, each of the payment instrument processors 265 are managed 

15 by third parties willing to grant authorizations based on transaction requests 
from the payment enabler 240 for specific dollar amounts. The payment 
instrument processors 265 may handle authorization requests from the payment 
enabler 240 in an automated manner. When a payment instrument processor 
265 grants an authorization for a specific dollar amount for a specified payment 

20 instrument, the managing third party thereby promises payment to the 
intermediary 120 and assumes the risk of nonpayment by the buyer 110. 

To use the consumer to consumer payment process, the payment enabler 
240 typically requires the buyer 110 to register a payment instrument and the 
seller 130 to register a disbursement instrument. At a minimum, registration 

25 of a financial instrument involves the payment enabler 240 receiving from the 
buyer 110 or the seller 130 basic identification information about the financial 
instrument necessary to make transaction requests for that instrument to the 
instrument processor 270, 275, 280, 285, or 290. Typically, the payment 
enabler 240 provides the identification information received from the consumer 
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to the appropriate processor 270, 275, 280, 285, or 290 in order to verify that 
the financial instrument exists. 

If the consumer is attempting to register a payment instrument, the 
appropriate payment instrument processor 265 may also perform additional 

5 background checks on the payment instrument to determine if the payment 
instrument processor will accept later authorization requests for that payment 
instrument. Such a background check may, for example, include verifying that 
the buyer 110 has completed the flash cash deposit, the buyer has completed the 
check deposit, the buyer has not fraudulently provided the credit card, the 

10 buyer does not have a history of overdrawing the bank account provided, or the 
virtual private payment account processor has a relationship with the entity 
offering the virtual private payment account. These preliminary background 
checks are intended to be different than authorization requests, which are later 
requests from the payment enabler 240 for a transaction on a financial 

15 instrument for a specific dollar amount at a specific point in time. The 
payment instrument processors 265 need not base these preliminary background 
checks on a consideration of specific amounts. Rather, the payment instrument 
processors 265 may base these preliminary background checks on whether the 
payment instrument the buyer 110 is attempting to register is in good standing. 

20 Preferably, the payment enabler 240 permits a given consumer to 

register both as a buyer 110 and as a seller 130. This allows the consumer to 
use the consumer to consumer payment service for multiple transactions, in 
some of which the consumer is a buyer 110 and in some of which the consumer 
is a seller 130. Furthermore, the payment enabler 240 may permit the 

25 consumer to register multiple payment instruments and multiple disbursement 
instruments. If the payment enabler 240 allows registration of multiple 
financial instruments, the payment enabler 240 may permit the consumer to 
identify a preferred payment instrument and a preferred disbursement 
instrument. Typically, the consumer can change the preferred financial 
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instrument at any time before confirming the consumer's desire to proceed with 
a given transaction. 

After the buyer 110 and the seller 130 have registered a financial 
instrument, the payment enabler obtains confirmation from both the buyer and 

5 the seller that they wish to proceed with the transaction. The payment enabler 
240 also requires the buyer 110 to specify the payment instrument and the 
seller 130 to specify the disbursement instrument to be used. The payment 
enabler 240 then obtains authorization for payment 140 from the buyer 110 
from the appropriate payment instrument processor 265, and the intermediary 

10 120 receives payment from that payment instrument processor in due course. 

After receiving authorization for payment 140, the payment enabler 240 
notifies the appropriate disbursement instrument processor 260 to pay the seller 
130 through the disbursement instrument chosen by the seller. The 
disbursement instrument processor 260 typically does this by drawing on funds 

15 in a bank account of the intermediary 120. 

In one embodiment, the payment enabler 240 does not pay the seller 130 
until the seller has delivered acceptable goods to the buyer 110 through an 
authorized shipping service. To monitor the status of a pending shipment, the 
payment enabler 240 may interface with a shipping service tracking database 

20 250. 

The shipping service tracking database 250 is maintained by the shipping 
service the seller 130 uses to ship the goods. When a parcel is sent through an 
authorized shipping service, the shipping service assigns the parcel a tracking 
number. For each parcel sent using the shipping service, the shipping service 

25 tracking database 250 stores the corresponding tracking number and delivery 
status. The shipping service tracking database 250 is functional for receiving a 
tracking number and replying with the status of the parcel corresponding to 
that tracking number. 

The payment enabler 240 (or the transaction facilitator 230) may also 

30 provide a Web page enabling both the buyer 110 and the seller 130 to request 
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the status of the parcel used to ship the goods. Once such a request has been 
received, the payment enabler 240 uses the tracking number to query the 
shipping service tracking database 250 for the status of the delivery. The 
payment enabler 240, in turn, relays the status of the delivery to the buyer 110 

5 or the seller 130 through a Web page. 

One procedure for tracking the shipment of goods requires the seller 130 
to notify the payment enabler 240 of the tracking number received from the 
shipping service. After the payment enabler 240 receives authorization for 
payment 140, the payment enabler notifies the seller 130 to ship the goods to 

10 the buyer 110. The seller 130 then ships the goods to the buyer 110 through an 
authorized shipping service and obtains a tracking number. The payment 
enabler 240 requires the seller 130 to enter this tracking number into the 
payment enabler. Using this tracking number, the payment enabler 240 can 
query the shipping service tracking database 250 to determine the delivery 

15 status of the goods. 

Alternatively, the payment enabler 240 may automatically provide the 
seller 130 with a tracking number to be used for shipping the goods. Upon 
receiving authorization for the payment 140, the payment enabler 240 may 
query the shipping service tracking database 250 to obtain a valid tracking 

20 number. Through a Web page, the payment enabler 240 then notifies the seller 
130 to ship the goods to the buyer 110 using the authorized shipping service 
and this predetermined tracking number. Then, the seller 130 delivers the 
goods to the shipping service along with the predetermined tracking number 
provided by the payment enabler 240. The shipping service, in turn, ships the 

25 goods using a parcel identified by the predetermined tracking number and 
appropriately maintains the shipping service tracking database 250. Because the 
payment enabler 240 provided the tracking number to the seller 130, the 
payment enabler knows the tracking number and can query the shipping service 
tracking database 250 for the delivery status of the goods. 
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Once the payment enabler 240 determines that the goods have been 
delivered to the buyer 110, the payment enabler may further determine if the 
goods are acceptable to the buyer 110 before paying the seller 130. The 
payment enabler 240 may make this determination by providing the buyer 110 

5 a predetermined amount of time, measured from the date of delivery indicated 
by the shipping service tracking database 250, to notify the payment enabler of 
rejection of the goods. If the buyer 110 notifies the payment enabler 240 that 
acceptable goods have been delivered or the buyer does not reject the goods 
within a predetermined time after the shipping service tracking database 250 

10 indicates that the goods have been delivered, the payment enabler 240 notifies 
the appropriate disbursement instrument processor 260 to pay the seller 130 
through the disbursement instrument chosen by the seller. 

One skilled in the art will appreciate that the present invention is not 
limited to the computer network architecture 200 of FIG. 2. Specifically, the 

15 functions described for the various computer nodes of FIG. 2 could be 
distributed differently. For instance, the functions of the payment enabler 240 
and the transaction facilitator 230 could be combined into a single computer 
node. Similarly, the payment enabler 240 could incorporate the functions of 
any of the payment instrument processors 265 or disbursement instrument 

20 processors 260. Although each of computer nodes 270, 275, and 280 perform 
both payment functions and disbursement functions for a given type of financial 
instrument, two different computer nodes could perform the payment functions 
and the disbursement functions for a given type of financial instrument. 
Furthermore, an existing merchant credit card processing system could be 

25 modified to incorporate functions of the payment enabler 240 and the credit 
card transaction processor 290, thereby enabling consumer to consumer 
payments through credit cards. 
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Flow Charts for the Consumer-to-Consumer Payment Process 
FIG. 3 shows the steps of an exemplary consumer-to-consumer payment 
process 300. The process 300 begins with step 310, in which interaction 
between the buyer 110 and the seller 130 through the transaction facilitator 230 
5 results in an agreed upon transaction for the sale of goods. The transaction 
facilitator 230 may, for example, be an online auction site, an online classifieds 
site, or any site which allows the seller 130 to sell goods to the buyer 110 
without requiring that the seller 130 be registered as a merchant. Preferably, 
the transaction facilitator 230 automatically passes the transaction details to the 
10 payment enabler 240. 

In step 320, the buyer 110 registers at least one payment instrument with 
the payment enabler 240. FIGS. 4A, 4B, 4C, 4D, and 4E describe the 
registration process for the various payment instruments available to the buyer 
110. 

15 In step 330, the seller 130 registers at least one disbursement instrument 

with the payment enabler 240. FIGS. 5 A, 5B, and 5C describe the registration 
process for the various disbursement instruments available to the seller 130. 

In step 340, the seller 130 selects a disbursement instrument that the 
seller has previously registered. The seller 130 then instructs the payment 

20 enabler 240 to disburse money due from the buyer 110 through the selected 
instrument. 

In step 350, the buyer 110 selects a payment instrument that the buyer 
110 has previously registered. The buyer 110 then instructs the payment 
enabler 240 to pay the seller 130 using the selected instrument. 
25 In step 360, the payment enabler 240 ensures completion of the 

transaction between the buyer 110 and the seller 130. The process 300 then 
ends in step 370. 

FIG. 4 A is a logical flow diagram illustrating the steps in an exemplary 
process for the registration of a flash cash deposit as a payment instrument. 
30 The buyer 110 may follow this routine in step 320 of FIG. 3. 
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The routine begins at step 41 OA, in which the payment enabler 240 
presents the buyer 110 with a graphical user interface enabling the buyer 110 to 
enter a deposit amount and information identifying the buyer. In step 420A, 
the buyer 110 enters the requested information through the graphical user 
5 interface. 

In step 430A, the payment enabler 240 creates a registration record for 
the flash cash deposit in a registration database stored by the payment enabler 
240. The registration record for the flash cash deposit stores identification 
information for the flash cash deposit instrument and indicates when the buyer 
10 110 has made the cash deposit in order to complete registration of the flash cash 
instrument. 

In step 440A, the payment enabler 240 stores a flag in the registration 
record to indicate that buyer 110 has not yet made the deposit. In step 450A, 
the payment enabler 240 provides the flash cash processor 285 with 

15 identification information for the buyer 110 and the deposit amount. The flash 
cash processor 285 stores this information in its own database. 

In step 460A, the buyer 110 physically goes to a deposit location 
registered with the flash cash processor 285. At the deposit location, the buyer 
110 deposits cash in the amount previously specified when setting up the deposit 

20 with the payment enabler 240. 

In step 470A, the deposit location electronically notifies the flash cash 
processor 285 that the buyer 110 has completed the prearranged deposit. In 
step 480A, the flash cash processor 285 notifies the payment enabler 240 that 
the buyer 110 has completed the prearranged deposit. 

25 Upon notification that the buyer 110 has completed the prearranged 

deposit, in step 490A, the payment enabler 240 updates the flag in the 
registration record to indicate that the buyer 110 has completed the deposit. 
The routine then returns in step 495A. 
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FIG. 4B is a logical flow diagram illustrating the steps in an exemplary 
procedure for the registration of a credit card as a payment instrument. The 
buyer 110 may follow this routine in step 320 of FIG. 3. 

The routine begins with step 41 0B, in which the payment enabler 240 
5 presents the buyer 110 with a graphical user interface enabling the buyer 1 10 to 
enter credit card registration information. In step 420B, the buyer 110 enters 
his name, address, card association, card number, and card expiration date 
through the graphical user interface. 

In step 430B, the payment enabler 240 provides the information entered 
10 by the buyer 110 to the credit card transaction processor 290 for registration 
processing. In step 440B, the credit card transaction processor 290 compares 
the address provided by the payment enabler 240 to the address of record for 
the credit card holder. Instead of performing the address verification 
comparison at the credit card transaction processor 290, the credit card 
15 transaction processor may forward the registration information entered by the 
buyer 110 to the credit card issuer, which performs the address comparison and 
reports the results of the comparison back to the credit card transaction 
processor. 

In step 450B, the credit card transaction processor 290 sends the payment 
20 enabler 240 a score indicating the degree to which the address provided by the 
payment enabler 240 and the address of record match. Such address matching 
analyses are known to those skilled in the art. 

In step 460B, the payment enabler 240 determines if the address matching 
score meets minimum requirements for registration. If the score does not meet 
25 the minimum requirements for registration, the "NO" branch is followed to 
step 480B. In step 480B, registration of the credit card is denied, and the 
routine returns in step 490B. 

Referring again to step 460B, if the score does meet minimum 
requirements for registration, then the "YES" branch is followed to step 470B. 
30 In step 470B, the payment enabler 240 creates a registration record for the 
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credit card. The registration record is stored in a registration database at the 
payment enabler 240. The routine then returns in step 490B. 

FIG. 4C is a logical flow diagram illustrating the steps in an exemplary 
process for registration of a bank account as a payment instrument via 
5 electronic fund transactions. The buyer 110 may follow this routine in step 320 
of FIG. 3. 

The routine begins with step 4 10C, in which the payment enabler 240 
presents the buyer 110 with the graphical user interface enabling the buyer 110 
to enter bank account registration information. In step 420C, the buyer 110 
10 enters his name. The buyer 110 also enters the routing number and account 
number for the bank account the buyer 110 wishes to register. 

In step 430C, the payment enabler 240 provides information entered by 
the buyer 110 to the electronic fund transaction processor 270 for registration 
processing. In step 440C, the electronic fund transaction processor 270 
15 processes the registration information by reviewing a negative history database 
to determine if there is negative history for the account. Such a negative 
history review is known to those skilled in the art. 

In step 45 0C, the electronic fund transaction processor 270 determines if 
significant negative history has been found. If significant negative history has 
20 been found, the "YES" branch is followed to step 480C, and registration of the 
bank account as a payment instrument is denied. In this case, the routine 
returns in step 490C. 

Referring again to step 450C, if significant negative history is not found, 
then the "NO" branch is followed to step 460C. In step 460C, the electronic 
25 fund transaction processor 270 notifies the payment enabler 240 that transaction 
requests will be accepted for the bank account. 

In step 470C, the payment enabler 240 creates a registration record 
indicating that the bank account has been registered for debiting in electronic 
fund transactions. This registration record is stored in a registration database 
30 at the payment enabler 240. The routine then returns in step 490C. 
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FIG. 4D is a logical flow diagram illustrating the steps in an exemplary 
process for the registration of a virtual private payment account as a payment 
instrument. The buyer 110 may follow this routine in step 320 of FIG. 3. 

The routine begins in step 410D, in which the payment enabler 240 
5 presents the buyer 110 with a graphical user interface enabling the buyer 110 to 
enter the virtual private payment account registration information. In step 
420D, the buyer 110 enters the account provider and the account number for 
the virtual private payment account. The buyer 110 enters this information 
through the graphical user interface presented to the buyer in step 410D. 

10 In step 430D, the payment enabler 240 determines if the account provider 

has been approved by the payment enabler 240. If the account provider has not 
been approved by the payment enabler 240, then the "NO" branch is followed 
to step 470D, in which registration of the virtual private payment account as a 
payment instrument is denied. In that case, the routine returns in step 480D. 

15 Referring again to step 430D, if the payment enabler 240 determines that 

the account provider has been approved by the payment enabler 240, then the 
"YES" branch is followed to step 440D. In step 440D, the payment enabler 240 
queries the virtual private payment account processor 275 of the account 
provider to determine if the processor will accept requests for debiting the 

20 virtual private payment account. The virtual private payment account 
processor 275, in response, notifies the payment enabler 240 if such requests 
will be accepted. 

In step 450D, the payment enabler 240 determines if these requests will 
be accepted. If requests for debiting the virtual private payment account will 
25 not be accepted, then the "NO" branch is followed to step 470D, in which 
registration of the virtual private payment account is a payment instrument is 
denied. The routine then returns in step 480D. 

Referring again to step 450D, if the payment enabler 240 is told by the 
virtual private payment account processor 275 that requests for debiting the 
30 virtual private payment account will be accepted, then the "YES" branch is 
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followed to step 460D. In step 460D, the payment enabler 240 creates a 
registration record that indicates that the virtual private payment account has 
been registered for debiting. The payment enabler 240 stores this registration 
record in a registration database at the payment enabler 240. The routine then 
5 returns in step 480D. 

FIG. 4E is a logical flow diagram illustrating the steps in an exemplary 
process for the registration of a physical check as a payment instrument. The 
buyer 110 may follow this routine in step 320 of FIG. 3. 

In step 410E, the payment enabler 240 presents the buyer 110 with the 
10 graphical user interface enabling the buyer 110 to enter identification 
information and a check amount. In step 420E, the buyer 110 enters the 
requested information through the graphical user interface. 

In step 430E, the payment enabler 240 creates a registration record for 
the check deposit in a registration database stored by the payment enabler 240. 
15 In step 440E, the payment enabler 240 stores a flag in the registration record to 
indicate that the buyer 110 has not yet made the check deposit. 

In step 450E, the payment enabler 240 provides the check processor 280 
with identification information for the buyer 110 and the check deposit amount. 
The check processor 280 stores this information and awaits receipt of the check 
20 from the buyer 110. 

In step 460E, the buyer 110 sends a physical check to an address specified 
by the check processor 280. In step 470E, the check arrives at the address 
specified by the check processor 280. The check processor 280 processes the 
check and obtains the payment specified by the check. 
25 In step 480E, the check processor 280 electronically notifies the payment 

enabler 240 that the buyer 110 has completed the prearranged check deposit. 
In step 490E, the payment enabler 240 updates the flag in the registration 
record to indicate that the buyer 110 has completed the check deposit. The 
routine then returns in step 495E. 
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FIG. 5A is a logical flow diagram illustrating the steps in an exemplary 
process for the registration of a bank account as a disbursement instrument via 
electronic fund transactions. The seller 130 may follow this routine in step 330 
of FIG. 3. 

5 In step 510A, the payment enabler 240 presents the seller 130 with a 

graphical user interface enabling the seller 130 to enter bank account 
registration information. In step 520A, the seller 130 enters the seller's name. 
The seller 130 also enters the routing number and account number for the bank 
account. The seller 130 enters this information through the graphical user 

10 interface presented to the seller in step 510A. 

In step 5 30 A, the payment enabler 240 provides the information entered 
by the seller 130 to the electronic fund transaction processor 270 for 
registration processing. In step 540A, the electronic fund transaction processor 
270 verifies the existence of the account and notifies the payment enabler 240 if 

15 the account exists. 

In step 550A, the payment enabler 240 determines if the payment enabler 
was notified that the account was found. If the account was not found, then the 
"NO" branch is followed to step 580A, and registration of the bank account as a 
disbursement instrument is denied. The routine then returns in step 590A. 

20 Referring again to step 550A, if the bank account was found, then the 

"YES" branch is followed to step 560A. In step 560A, the electronic fund 
transaction processor 270 notifies the payment enabler 240 that the electronic 
fund transaction requests will be accepted for the bank account. 

In step 570A, the payment enabler 240 creates a registration record 

25 indicating that the bank account has been registered for crediting in electronic 
fund transactions. This registration record is stored in the database at the 
payment enabler 240. The routine then returns in step 590A. 

FIG. 5B is a logical flow diagram illustrating the steps in an exemplary 
process for registration of a virtual private payment account as a disbursement 

30 instrument. The seller 130 may follow this routine in step 330 of FIG.3. 
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The routine begins in step 51 OB, in which the payment enabler 240 
presents the seller 130 with a graphical user interface enabling the seller 130 to 
enter the virtual private payment account registration information. In step 
520B, the seller 130 enters the account provider and the account number for 

5 the virtual private payment account. The seller 130 enters this information 
through the graphical user interface presented to the seller in step 51 0B. 

In step 530B, the payment enabler 240 determines if the account provider 
entered by the seller 130 has been approved by the payment enabler 240. If the 
account provider has not been approved by the payment enabler 240, then the 

10 "NO" branch is followed to step 550B. In step 550B, registration of the virtual 
private payment account as a payment instrument is denied. The procedure 
then returns in step 560B. 

Referring again to step 530B, if the account provider has been approved 
by the payment enabler 240, then the "YES" branch is followed to step 540B. 

15 In step 540B, the payment enabler 240 creates a registration record indicating 
that the virtual private payment account has been registered for crediting. The 
registration record is stored in a database at the payment enabler 240. The 
routine then returns in step 560B. 

FIG. 5C is a logical flow diagram illustrating the steps in an exemplary 

20 process for registration of a mailed check as the disbursement instrument. The 
seller 130 may follow this routine in step 330 of FIG. 3. 

The routine begins in step 5 10C, in which the payment enabler 240 
presents the seller 130 with a graphical user interface enabling the seller 130 to 
enter registration information for receiving disbursements through a mailed 

25 check. In step 520C, the seller 130 uses the graphical user interface to enter the 
seller's name and the address to which the seller wants the check processor 280 
to mail disbursement checks. 

In order to register to receive a mailed check disbursement instrument, 
the payment enabler 240 also requires that the seller 130 register a credit card. 

30 Registration of a credit card provides protection to the intermediary 120 
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because the payment enabler 240 can charge the credit card in order to refund 
the buyer 110 should the seller 130 cash the disbursement check and disappear 
in a fraudulent transaction. The credit card can also be used to refund the 
buyer 110 in the event of a chargeback. Thus, in step 530C, the payment 
5 enabler 240 requires the seller 130 to enter credit card information, including 
the card association of the credit card, the card number, and the card expiration 
date. The seller 130 enters this information through a graphical user interface 
provided by the payment enabler 240. 

In step 540C, the payment enabler 240 provides the information entered 

10 by the seller 130 to the credit card transaction processor 290 for registration 
processing. In step 550C, the credit card transaction processor 290 compares 
the address provided by the payment enabler 240 to the address of record for 
the credit card holder. Instead of performing the address verification 
comparison at the credit card transaction processor 290, the credit card 

15 transaction processor may forward the registration information entered by the 
buyer 110 to the credit card issuer, which performs the address comparison and 
reports the results of the comparison back to the credit card transaction 
processor. In step 560C, the credit card transaction processor 290 sends the 
payment enabler 240 a score indicating the degree to which the address 

20 provided by the payment enabler 240 matches the address of record for the 
credit card holder. 

In step 570C, the payment enabler 240 determines if the score meets 
minimum requirements for registration of the credit card. If the score does not 
meet the minimum requirements for registration, then the "NO" branch is 

25 followed to step 590C, and the payment enabler 240 tells the seller 130 that the 
seller cannot register to receive disbursements through mailed checks until the 
seller provides a valid credit card with a matching address. The routine then 
returns in step 595C. 

Referring again to step 570C, if the score returned by the credit card 

30 transaction processor 290 does meet minimum requirements for credit card 
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registration, then the "YES" branch is followed to step 580C. In step 580C, the 
payment enabler 240 creates a registration record that indicates that the seller 
130 can receive mailed check disbursements. This record includes the address 
to which the check disbursement should be mailed, as well as the credit card 
5 information needed to protect against fraud and to enable chargebacks. This 
registration record is stored in a database at the payment enabler 240. The 
routine then returns in step 595C. 

FIG. 6 is a logical flow diagram illustrating exemplary steps for 
completing routine 360 on FIG. 3. Routine 360 also appears on FIGS. 9, 10 
10 and 11. The routine 360 contains exemplary steps that the payment enabler 240 
can follow to ensure completion of the transaction between the buyer 110 and 
the seller 130. 

Routine 360 begins with step 610. In step 610, the payment enabler 240 
seeks an authorization for payment of the amount buyer 110 owes seller 130. 
15 The payment enabler 240 seeks this authorization from the payment instrument 
processor 265 associated with the payment instrument selected by the buyer 
110. The payment enabler 240 notifies the payment instrument processor 265 
that the recipient of the authorized payment should be a bank account of the 
intermediary 120. 

20 Generally, authorization refers to the point at which the payment enabler 

240 passes the risk of non-payment by the buyer 110 to the entity running the 
payment instrument processor 265 from which authorization is sought. For 
flash cash, authorization is defined at which the flash cash processor 285 
notifies the payment enabler 240 that the buyer 110 has completed the 

25 prearranged deposit in step 480A of FIG. 4A. Thus, for flash cash, 
authorization automatically occurs during the registration process of FIG. 4 A. 
Similarly, authorization for a physical check occurs automatically during the 
registration process of FIG. 4E in step 480E, in which the check processor 280 
electronically notifies the payment enabler 240 that the buyer 110 has 

30 completed the prearranged check deposit. This is true even though the bank 
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account of the intermediary 120 may not yet have received the associated 
payment. 

For a credit card transaction, the authorization process is well understood 
by those skilled in the art. Specifically, the payment enabler 240 provides a 
5 payment request to the credit card transaction processor 290. This charge 
request includes the payment amount and the credit card information. In the 
manner known to those skilled in the art, the credit card transaction processor 
290 determines whether or not to accept this charge, a decision typically based 
on the credit card's spending limit, the card's current balance, and the amount 

10 of the authorization request. If the charge is accepted by the credit card 
transaction processor 290, the credit card transaction processor 290 generates 
an authorization number, which the credit card transaction processor 290 
provides to the payment enabler 240. Upon authorization, the intermediary 
120 is assured payment, and the risk of loss has passed to the credit card 

15 transaction processor 290. 

For payment by the buyer 110 through an electronic fund transaction, an 
authorization is also obtained through methods known to those skilled in the art. 
Specifically, the payment enabler 240 makes an electronic fund transaction 
request of the electronic fund transaction processor 270. This transaction 

20 request includes the dollar amount, as well as the routing number and the 
account number of the account to be debited. The electronic fund transaction 
processor 270 determines whether to grant the authorization based upon a 
number of factors, including the dollar amount of the debit request and the 
current account balance. If the electronic fund transaction processor 270 grants 

25 the authorization, the electronic fund transaction processor 270 assumes the risk 
of non-payment by the buyer 110 and notifies the payment enabler 240 that 
authorization is granted. 

Authorization for a debiting of a virtual private payment account may 
occur in a manner analogous to debiting a bank account in an electronic fund 

30 transaction. 
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The payment enabler 240 may provide the buyer 110 with a 
predetermined number of attempts to obtain an authorization. Different 
attempts may be with the same instrument, or the different attempts may be 
with different instruments. 
5 In step 620, the payment enabler 240 determines if an authorization was 

obtained for the payment instrument selected by the buyer 110. If 
authorization was not obtained, then the "NO" branch is followed to step 680, 
and the routine returns. If, in step 620, authorization was obtained, then the 
"YES" branch is followed to step 630. 

10 Once authorization has been obtained, the intermediary 120 is assured 

payment because the payment enabler 240 has passed to another party the risk 
of non-payment by the buyer 110. Thus, the intermediary 120 obtains the 
amount due automatically at a later time. In step 630, the bank account of the 
intermediary 120 receives deposit of the amount authorized for the payment 

15 instrument. However, in the case of a transfer of money from a virtual private 
payment account of the buyer 110 to a virtual private payment account of the 
seller 130, the money need not pass through a bank account of the intermediary 
120, but rather can occur directly at the request of the payment enabler 240. 

The collection of money from the buyer 110 and the transfer of that 

20 money to the bank account of the intermediary 120 occurs in the manner 
known to those skilled in the art. In the case of flash cash, the flash cash 
processor 285 coordinates a direct deposit into the bank account of the 
intermediary 120. The credit card transaction processor 290 coordinates 
settlement in the typical way for credit cards. The electronic fund transaction 

25 processor 270 uses the automated clearing house to accomplish settlement. The 
virtual private payment account processor 275 generates settlement by debiting 
the virtual private payment account of the buyer 110 and generating a direct 
deposit into the bank account of the intermediary 120. The check processor 
280 may also generate a direct deposit into the bank account of the 

30 intermediary 120 to remit payment to the intermediary 120. 
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In step 640, the payment enabler 240 verifies delivery of acceptable 
goods to the buyer 110. In step 650, the payment enabler 240 determines if the 
seller has delivered acceptable goods to the buyer 110. If acceptable goods 
have been delivered, then the "YES" branch is followed to step 670, in which 

5 the payment enabler 240 transfers the amount buyer 110 owes seller 130 from 
a bank account of the intermediary 120 to the seller through the disbursement 
instrument selected by the seller 130. The routine then returns in step 680. 

The disbursement transfer in step 670 is accomplished in the manner 
known to those skilled in the art. For example, in the case of an electronic fund 

10 transaction, the payment enabler 240 generates a request to the electronic fund 
transaction processor 270 to credit the bank account of the seller 130 and debit 
the account of the intermediary 120. The electronic fund transaction processor 
270 processes this request through the automated clearing house. In the case of 
a virtual private payment account selected as the disbursement instrument, the 

15 payment enabler 240 draws funds from the account of the intermediary 120 in 
order to pay the virtual private payment account host, which credits the virtual 
private payment account of seller 130. In the case of a physical check chosen as 
the disbursement instrument, the payment enabler 240 instructs the check 
processor 280 to cut a check drawn on a bank account of the intermediary 120. 

20 Referring again to step 650, if the payment enabler 240 determines that 

acceptable goods have not been delivered, then the "NO" branch is followed to 
step 660. In step 660, the payment enabler 240 refunds the money to the buyer 
110, possibly contingent upon the return of the unacceptable goods to the seller 
130. The routine then returns in step 680. 

25 FIG. 7 is a logical flow diagram illustrating exemplary steps for 

completing routine 640 on Fig 6. In routine 640, the payment enabler 240 
verifies the delivery of acceptable goods to the buyer 110. 

The routine 640 begins with step 710, in which the payment enabler 240 
notifies the seller 130 that payment is guaranteed upon receipt and acceptance 
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of goods by the buyer 110. In step 720, the payment enabler 240 instructs the 
seller 130 to ship the goods to the buyer 110 via an approved shipping service. 

In step 730, the seller 130 ships the goods through an approved shipping 
service that provides the seller with a tracking number for tracking delivery of 
5 the goods. In step 740, the seller 130 notifies the payment enabler 240 of the 
tracking number through a graphical user interface provided by the payment 
enabler. The payment enabler 240 then stores this tracking number. 

The payment enabler 240 also provides an interface to both the buyer 110 
and seller 130 that permits them to track the delivery of the goods through the 

10 shipping service. To get this information, the payment enabler 240 queries the 
shipping service tracking database 250 using the tracking number. 

In step 750, the payment enabler 240 periodically queries the shipping 
service tracking database 250 until the database indicates a date of delivery of 
the goods to the buyer 110. Alternatively, the payment enabler 240 could 

15 register with the shipping service tracking database 250 so that the shipping 
service tracking database 250 can automatically notify the payment enabler 240 
when the goods have been delivered to the buyer 110. 

When using the consumer-to-consumer service of the payment enabler 
240, the buyer 110 is informed that he should inform the payment enabler of 

20 his acceptance or rejection of the goods upon delivery. The buyer 1 10 is also 
warned that the goods will be deemed acceptable if the buyer 110 registers 
neither an acceptance nor a rejection of the goods within a predetermined 
amount of time of the delivery date. In step 760, the payment enabler 240 
determines if the buyer 110 has notified the payment enabler 240 of rejection 

25 of the goods within a predetermined amount of time of the delivery date. If so, 
the "YES" branch is followed to step 770, in which the payment enabler 240 
determines that acceptable goods have not been delivered. The routine then 
returns in step 790. 

Referring again to step 760, if the payment enabler 240 determines that 

30 the buyer 110 has not notified the payment enabler of the rejection of good 
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within a predetermined amount of time of the delivery date, then the "NO" 
branch is followed to step 780, in which the payment enabler 240 determines 
that acceptable goods have been delivered. In this case, the buyer 110 has 
notified the payment enabler 240 of the acceptance of goods through a 
5 graphical user interface or the buyer has failed to reject the goods within the 
predetermined time period. The routine then returns in step 790. 

FIG. 8 is a logical flow diagram illustrating exemplary steps completed 
by routine 660 on FIG. 6. The routine 660 provides exemplary steps the 
payment enabler 240 can follow to refund money to the buyer 110 who has 

10 rejected the goods delivered by the seller. 

The routine 660 begins with step 810, in which the payment enabler 240 
notifies the seller 130 that the buyer 110 has rejected the goods. In step 820, 
the payment enabler 240 instructs the buyer 110 to ship the goods back to the 
seller 130 via an approved shipping service. 

15 In step 830, the buyer 110 ships the goods via an approved shipping 

service that provides the buyer 110 with a tracking number for tracking 
delivery of the goods. In step 840, the buyer 110 notifies the payment enabler 
240 of the tracking number, allowing both buyer 110 and seller 130 to track 
delivery of the returned goods through a graphical user interface. 

20 In step 850, the payment enabler 240 periodically queries the shipping 

service tracking database 250 until the tracking database 250 indicates a date of 
delivery. In step 860, the payment enabler 240 determines if the seller 130 has 
notified the payment enabler of rejection of the returned goods within a 
predetermined amount of the time of the delivery date. If so, the "YES" 

25 branch is followed to step 870, and the payment enabler 240 refuses to make 
any further transfer of the money until the dispute is resolved. The routine 
then returns to step 890. 

Referring again to step 860, if the seller 130 has not notified the payment 
enabler 240 of rejection of the goods within a predetermined amount of the 

30 time of the delivery date, then the "NO" branch is followed to step 880. In step 
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880, the payment enabler 240 refunds the money to the buyer 110, less the 
charge for the consumer-to-consumer payment service. The routine then 
returns in step 890. 

5 Consumer-to-Consumer Payments in an Auction Environment 

FIG. 9 is a logical flow diagram illustrating exemplary steps in an auction 
process 900 that includes consumer-to-consumer payments facilitated by the 
payment enabler 240. The process includes static registration of the buyer 110 
and the seller 130 with the payment enabler 240. 

10 The auction process may occur through any of the Web auction sites that 

are well-known to users of the Internet. A Web auction site, such as EBAY or 
YAHOO! AUCTION, allows a seller 130 to post an object for sale on the Web 
site. Numerous bidders then bid on the item on the Web site, leading to a single 
winning bidder, who becomes the buyer 110. 

15 Static registration occurs when both the buyer 110 and the seller 130 

register their financial instruments with the payment enabler 240 prior to the 
bidding process. In contrast, dynamic registration occurs when the buyer 110, 
the seller 130, or both the buyer 110 and the seller 130 register with the 
payment enabler 240 after the bidding process. 

20 Registration with the payment enabler 240 need not be tied to any 

particular auction item. The registration process also need not be limited to 
registering a particular consumer as a buyer 110 or a seller 130. Specifically, 
any consumer registering with the payment enabler 240 may register to be a 
buyer 110, a seller 130, or both a buyer 110 and a seller 130, so long as the 

25 consumer registers appropriate payment or disbursement instruments. During 
registration, the consumer may register multiple payment instruments and 
multiple disbursement instruments. The consumer may also pick a preferred 
disbursement instrument and a preferred payment instrument, which the 
consumer can change when directing the payment enabler 240 to proceed with a 

30 specific transaction. 
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The auction process 900 begins with step 910, in which the buyer 1 10 and 
seller 130 separately register for participation in a Web-based auction site, 
which is the transaction facilitator 230 of FIG. 2. Registration with the auction 
site 230 is different from registration with the payment enabler 240 because 
5 registration simply enables the buyer 110 and seller 130 to participate in online 
auctions; no payment or disbursement instruments need to be registered at this 
point. Upon registration with the auction site, both the buyer 110 and the seller 
130 receive a unique user ID from the auction site. This user ID identifies the 
buyer 110 and the seller 130 in any transactions in which they participate. 

10 In step 920, the buyer 110 registers with the payment enabler 240 by 

specifying payment instruments. Typically, the buyer 110 is transferred to the 
registration Web page of the payment enabler 240 either by choosing a menu 
option that appears when the buyer logs onto the auction site 230 or by clicking 
on a hyperlink in an e-mail promoting the consumer-to-consumer payment 

15 service. Preferably, the Web page provided by the payment enabler 240 is 
branded identically with the auction site 230. Furthermore, the auction site 230 
preferably passes the buyer user ID to the payment enabler 240 for use as the 
registration record key. By automatically passing this buyer user ID from the 
auction site 230 to the payment enabler 240, the payment enabler and the 

20 auction site can present an integrated experience to the buyer 110 in which the 
buyer never realizes he is at a different site. 

In step 930, the seller 130 registers with the payment enabler 240 by 
specifying disbursement instruments. Typically, the seller 130 is transferred to 
the registration Web page of the payment enabler 240 either by choosing a 

25 menu option that appears when the seller logs onto the auction site 230 or by 
clicking on a hyperlink in an e-mail promoting the consumer-to- consumer 
payment service. Preferably, the Web page provided by the payment enabler 
240 is branded identically with the auction site 230. Furthermore, the auction 
site 230 preferably passes the seller user ID to the payment enabler 240 for use 

30 as the registration record key. By automatically passing this seller user ID 
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from the auction site 230 to the payment enabler 240, the payment enabler and 
the auction site can present an integrated experience to the seller 130 in which 
the seller never realizes he is at a different site. 

In step 940, the bidding process occurs, and the buyer 110 wins the 
5 bidding process for the item (goods) of the seller 130. At this point, the 
auction site 230 assigns a unique transaction ID for use as a key to a record 
storing the transaction details. These transactions details include the item, the 
price, and the identification of the buyer 110 and the seller 130 through the 
buyer user ID and the seller user ID. 

10 In step 950, the buyer 110 notifies the auction site of the desire of the 

buyer 110 to pay the seller 130 through the services of the payment enabler 
240. The buyer 110 may be transferred to a Web page for performing this 
notification by clicking on a hyperlink in an e-mail notifying the buyer of his 
winning bid. Alternatively, the buyer 110 may discover he was the winning 

15 bidder by perusing recent transactions after logging onto the auction site 230, 
and the buyer may then choose a menu hyperlink to a Web page for notifying 
the auction site of a desire to use the consumer-to-consumer payment service. 

In step 960, the auction site provides the transaction details to the 
payment enabler 240, which stores the information in a database. These details 

20 may include the transaction ID so that the auction site and the payment enabler 
240 can communicate about the particular transaction. 

Upon notification that the buyer 110 desires to pay the seller 130 through 
the services of the payment enabler 240, the seller selects a registered 
disbursement instrument in step 970. The seller 130 also creates an electronic 

25 invoice for the transaction through a Web page provided by the payment 
enabler 240. This invoice may include the bid price, the shipping charges, the 
handling charges, and the total price. Handling charges may be those fees 
charged by the payment enabler 240 for use of the consumer-to- consumer 
payment service. 
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The buyer 110 then learns from perusing his account or reading an e- 
mail that the invoice has been created. By clicking on a hyperlink in the e-mail 
or by navigating appropriately through the interface provided by the auction 
site 230, the buyer 110 directs his browser to the electronic invoice Web page 
5 of the payment enabler 240. In step 980, the buyer 110 reviews this invoice. 

The buyer 110 may disagree with the terms stated in the invoice. For 
example, the buyer 110 may disagree with the shipping charges. If that is the 
case, there may be an opportunity for the buyer 110 to negotiate the terms 
stated in the invoice through electronic messages, sent either in e-mail form or 
10 through a Web site provided by the payment enabler 240, with the seller 130. 

In step 990, the buyer 110 selects a registered payment instrument. By 
doing so, the buyer 110 also instructs the payment enabler 240 to pay the seller 
130 using the selected instrument. 

In step 360, the payment enabler 240 ensures completion of the 
15 transaction between the buyer 110 and the seller 130. The process 900 then 
ends in step 995. 

FIG. 10 is a logical flow diagram illustrating the steps of an exemplary 
auction process 1000 that incorporates dynamic registration of the buyer 110 
with the payment enabler 240. Auction process 1000 of FIG. 10 is similar to 

20 the auction process 900 of FIG. 9, except that in the auction process 1000, the 
buyer 110 registers with the payment enabler 240 after the bidding process, 
instead of before the bidding process. 

Specifically, after the buyer 1 10 notifies the auction site in step 950 that 
the buyer wishes to pay the seller 130 through the payment enabler 240, the 

25 auction site in step 1010 then redirects the buyer's browser to the registration 
page of the payment enabler 240 so that the buyer can register. At that point, 
in step 920, the buyer 110 registers with the payment enabler 240 through an 
identically branded Web page provided by the payment enabler 240. After step 
920, the auction process 1000 proceeds as in the auction process 900 of FIG. 9. 
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FIG. 1 1 is a logical flow diagram illustrating the steps of an exemplary 
auction process 1100 that incorporates dynamic registration of the seller 130 
with the payment enabler 240. Again, the auction process 1 100 of FIG. 1 1 is 
similar to the auction process 900 of FIG. 9, except that in the auction process 

5 1100, the seller 130 registers with the payment enabler 240 after the bidding 
process, instead of before the bidding process. 

Specifically, the buyer 110 wins the bidding in step 940. In step 950, the 
buyer 110 notifies the auction site of the buyer's desire to pay the seller 130 
through the payment enabler 240. Then, in step 1110, the auction site 230 

10 enables the buyer 110 to request that the seller 130 register with the payment 
enabler 240, because the seller 130 has not yet registered a disbursement 
instrument for receiving the buyer's payment. To notify the seller 130 of the 
request for registration by the buyer 110, the payment enabler 240 may send 
the seller an e-mail. The seller then registers with the payment enabler 240 in 

15 step 930. Subsequently, the auction process 1100 proceeds as in the auction 
process 900 of FIG. 9. 

Therefore, a method for offering a consumer to consumer payment 
service over a computer network has been described. Other alternative 
embodiments will become apparent to those skilled in the art to which an 

20 exemplary embodiment pertains without departing from its spirit and scope. 
Accordingly, the scope of the present invention is defined by the appended 
claims rather than the foregoing description. 

Personal Merchant Accounts 

25 The consumer-to-consumer payment process 300 can be modified to 

provide a personal merchant account to an individual consumer. These 
personal merchant accounts may be managed by the payment enabler 240. 
Generally, a personal merchant account allows an individual seller 130 to create 
and manage an online cash register. Once the seller 130 has created the online 

30 cash register, any given buyer 110 may use the online cash register to pay the 
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seller 130 for goods through any one of a variety of payment instrument types 
the seller has chosen to offer through the online cash register. In a typical 
embodiment, the online cash register is a Web page form for receiving payment 
instrument information. 

The online cash register that the seller 130 creates through the seller's 
personal merchant account can facilitate transactions between the seller and 
multiple buyers. The personal merchant account can also provide the seller 130 
with tools for managing these multiple transactions. Specifically, the personal 
merchant account may provide the seller with online backroom capabilities. 
Typically, the payment enabler 240 provides these backroom capabilities to the 
seller 130 through graphical user interfaces, such as Web pages. 

These backroom capabilities enable the seller 130 to view information 
about all completed transactions for which the seller has been paid and all 
pending transactions for which the seller has not yet been paid. Also, the 
backroom capabilities may enable the seller 130 to view orders which the seller 
130 needs to fulfill for customers. These backroom capabilities may further 
provide the seller 130 with tools for monitoring shipments of goods to the 
various buyers. Furthermore, the backroom capabilities may calculate the total 
revenues collected by the seller 130 through the online cash register. Other 
backroom capabilities, which are known to those skilled in the art, may be 
available through the personal merchant account. 

Typically, the personal merchant account and the online cash register are 
integrated with the transaction facilitator 230. The transaction facilitator 230 
may, for example, be an online auction site, an online classifieds site, or an 
online shopping mall at which the seller 130 has a virtual storefront for selling 
a variety of goods. Thus, the seller 130 may be referred to the payment 
enabler 240 for creation of the personal merchant account and the online cash 
register by the transaction facilitator 230. Similarly, the seller 130 may access 
the backroom capabilities of the seller's personal merchant account through a 
link from the transaction facilitator 230. Upon facilitating an agreement for 

42 



Attorney Docket No. 06042-0160 



the sale of goods from the seller 130 to the buyer 110, the transaction 
facilitator 230 may automatically send the buyer to the seller's online cash 
register in order to pay. 

To create an online cash register, the seller 130 first determines what 
payment methods the seller wishes to offer through the online cash register. 
Typically, the seller 130 can select payment instrument types from a graphical 
user interface provided by the payment enabler 240. For each payment 
instrument type selected by the seller 130, the payment enabler 240 usually 
requires the seller to undergo an approval or underwriting process. 

When creating the online cash register, the seller 130 also registers a 
disbursement instrument for receiving payment from the buyer 110. The 
procedure for registering a disbursement instrument may be analogous to any 
of the disbursement instrument registration procedures of FIGS. 5A-5C. 

When creating the online cash register, the seller 130 typically also 
defines additional charges to be added to the price at which the seller agreed to 
sell goods to the buyer 110. Such additional charges may include sales tax, 
shipping charges, and handling charges (i.e., the money the payment enabler 
240 charges for processing the payment of the buyer 110). Once the seller 130 
has defined these additional charges, the online cash register automatically 
calculates these additional charges and a total price that includes the sale price 
of the goods plus the additional charges. The online cash register then presents 
a display of the sale price of the goods, the additional charges, and the total 
price to the buyer 110 for payment. 

The additional charges may be predefined by the seller 130 through the 
use of tables or formulas. For example, the seller 130 may require sales tax to 
be calculated as a percentage of the sale price of the goods, and the seller may 
further define the percentage to be used in this calculation in a table that 
associates a percentage with each possible state in which the buyer 110 may 
live. Similarly, the seller 130 may define a table of shipping charges that vary 
depending on the weight of the item, the size of the item, and the address of the 
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buyer 110. Alternatively, the seller 130 may manually enter the additional 
charges for a particular transaction after agreeing to sell goods to the buyer 
110 for a specified price. 

In order to limit the danger of fraud and chargebacks, the payment 

5 enabler 240 may require the seller 130 to undergo an underwriting or approval 
process before receiving a personal merchant account. This approval process 
may be similar to the approval process a retail business must undergo to 
become a merchant and may vary depending on the particular instrument 
type(s) that the seller wants to accept through the online cash register. 

10 Typically, the payment enabler 240 retrieves information on which the 

approval decision is based through a graphical user interface provided to the 
seller 130 for creation of the online cash register. Furthermore, the payment 
enabler 240 may query additional sources based upon the information received 
from the seller 130 in order to obtain additional information that the payment 

15 enabler considers in the approval process. In determining whether or not to 
approve the seller 130 for the personal merchant account or for accepting 
payments through a particular payment instrument type, the payment enabler 
240 may require the seller 130 to provide such information as the seller's 
name, address, social security number, e-mail address, estimated total sales for 

20 the products to be sold, type of products to be sold, how long the seller has 
been associated with the transaction facilitator 230, feedback received by the 
transaction facilitator 230 from customers of the seller, and the credit history 
of the seller. The payment enabler 240 may submit the information received 
from the seller 130 to a remote computer node (not shown) for performing the 

25 underwriting process. 

The payment enabler 240 may make an automated decision whether or 
not to approve the seller 130 for the personal merchant account or for 
accepting a payment instrument type through an online cash register. The 
payment enabler 240 may base this automated decision upon information 
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provided by the seller 130 to the payment enabler and further information 
about the seller that the payment enabler obtains from other sources. 

Alternatively, the payment enabler 240 may determine that the seller 130 
does not meet the criteria for either automated approval or automated rejection. 
5 In that case, the payment enabler 240 may refer the underwriting process to a 
human credit manager for further review. In this further review, the human 
credit manager may request additional information from the seller 130 or 
request additional information from other sources. After final decision, the 
human credit manager informs the payment enabler 240 whether or not to 
10 approve the seller 130 for the personal merchant account or for the payment 
instrument type under review. 

When performing the underwriting assessment of the seller 130, the 
payment enabler 240 may rate the seller using tiered risk assessment criteria. 
For example, the payment enabler 240 may process the information provided 
15 by the seller 130 to determine if the seller is high risk, medium risk, or low 
risk for fraud and chargebacks. The payment enabler 240 may inform 
potential buyers of the tier into which the payment enabler has placed the seller 
130, thereby helping a buyer 110 to determine whether or not to do business 
with the seller. Similarly, the tier into which the payment enabler 240 places 
20 the seller 130 for a particular payment instrument type may determine the 
maximum amount the seller 130 can receive through that payment instrument 
for any single transaction. Also, the tier into which the payment enabler 240 
places the seller 130 may determine whether or not the payment enabler refers 
the underwriting process to a human credit manager. 
25 After the seller 130 creates an online cash register, the seller 130 may 

then provide the online cash register to buyers in order to receive payment for 
the sale of goods. Also, the seller 130 may use the backroom capabilities of the 
personal merchant account to view transactions completed through the online 
cash register. 
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Handling of the payment process through the online cash register occurs 
in a manner analogous to that for the consumer-to-consumer payment process 
300. The transaction facilitator 230 provides the payment enabler 240 with the 
details of a transaction between the buyer 110 and the seller 130. The payment 
5 enabler 240 then provides the online cash register for the seller 130 to the 
buyer 110. The online cash register displays the sale price of the goods the 
buyer 110 is buying from the seller 130. The online cash register also displays 
any additional charges the seller 130 wishes to charge the buyer 110. Further, 
the online cash register includes a form allowing the buyer 110 to pay the total 

10 price using any of the payment instrument types for which the seller 130 has 
sought and received approval. 

In response to viewing the online cash register, the buyer 110 enters 
registration information for a payment instrument of one of the payment 
instrument types available through the online cash register. This registration 

15 process for the buyer 110 may be similar to the registration process shown in 
any of FIGS. 4A-4E, which are used in the consumer-to-consumer payment 
process 300. As with the consumer-to-consumer payment process 300, the 
payment enabler 240 may store the registration information for the payment 
instrument. In that way, the payment enabler 240 may process requests from 

20 the buyer 110 to pay the seller 130 without ever providing the registration 
information for the payment instrument to the seller. This eliminates any 
necessity for providing the seller 130 with a general authorization to charge 
payment instruments such as credit cards, thereby reducing the danger of fraud. 
After registration of a payment instrument, the buyer 110 can then 

25 instruct the online cash register provided by the payment enabler 240 to pay the 
seller 130. The payment enabler 240 then obtains an authorization for a 
transfer of the total price indicated by the online cash register from the buyer 
110 through the payment instrument to a first intermediary bank account of the 
intermediary 120. Next, the payment enabler 240 orders a transfer of the total 

30 price from a second intermediary bank account through a pre-registered 
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disbursement instrument to the seller 130. The first intermediary bank account 
and the second intermediary bank account may be identical, or they may be 
owned by the same entity. 

When the online cash register receives instructions from the buyer 110 to 
5 pay the seller 130 a total price indicated by the online cash register, the 
payment enabler 240 assigns the transaction a unique reference number. 
Through the backroom capabilities of the personal merchant account, the seller 
130 can view pending and past transactions and their associated reference 
numbers. The seller 130 can also use this reference number to refer to the 

10 specific transaction when contacting the intermediary 120 to discuss a 
transaction, such as during fraud investigations and chargebacks. 

Before, during, and after the online cash register's payment process, the 
payment enabler 240 may perform fraud detection analyses for detecting fraud 
by the buyer 110 or the seller 130. Such fraud detection methods are known to 

15 those skilled in the art. Preventing fraud may further include authenticating the 
buyer 110 and the seller 130 before processing a transaction. 

FIG. 12 is a logical flow diagram of an exemplary online cash register 
creation process 1200. The process 1200 begins with step 1210, in which the 
seller 130 provides the payment enabler 240 with identification information 

20 about the seller and requests a personal merchant account. In step 1220, the 
payment enabler 240 creates the personal merchant account. The seller 130 can 
then access this account at any time through a link from the transaction 
facilitator 230. 

In step 1230, the seller 130 registers a disbursement instrument with the 
25 payment enabler 240. The payment enabler 240 can use this disbursement 
instrument for transferring payment to the seller 130 after receipt of the 
payment through the online cash register. 

In step 1240, the seller 130 selects the payment instrument types the seller 
wishes to offer through the online cash register. In step 1250, the payment 
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enabler 240 requests and receives underwriting assessment information for each 
payment instrument type selected by the seller in step 1240. 

In step 1260, the payment enabler performs an underwriting assessment 
for each payment instrument type to determine whether to let the seller 130 
5 offer that payment instrument type in the seller's online cash register. This 
underwriting assessment is based upon the underwriting assessment information 
received in step 1250. 

In step 1270, the payment enabler 240 determines if the seller 130 has 
been approved for at least one payment instrument type. If the seller 130 has 

10 not been approved for at least one payment instrument type, then the "NO" 
branch is followed to step 1290, and the seller is denied an online cash register. 
The process 1200 then ends in step 1295. 

Referring again to step 1270, if payment enabler 240 determines that the 
seller 130 has been approved for at least one payment instrument type, then the 

15 "YES" branch is followed to step 1280. In step 1280, the payment enabler 240 
permits the seller 130 to define additional charges to be added automatically by 
the online cash register to the sale price of any goods. Such additional charges 
may include sales tax, shipping charges, and handling charges. 

As shown in step 1285, the creation of the online cash register is 

20 complete. The payment enabler 240 will provide the online cash register to 
each buyer 110 who agrees to buy goods from the seller 130. Through the 
online cash register, the buyer 110 can then pay the seller 130 through any 
payment method for which the seller 130 has been approved through the 
underwriting process. The process 1200 then ends in step 1295. 

25 The logical flow diagram shown in FIG. 12 illustrates one embodiment in 

which the payment enabler 240 performs an underwriting assessment for each 
payment instrument type. Alternatively, the payment enabler 240 may perform 
a single underwriting assessment prior to approving the seller 130 for a 
personal merchant account. In this alternative embodiment, the personal 



48 



Attorney Docket No. 06042-0160 

merchant account is not created until the seller 130 is approved by the payment 
enabler 240. 

FIG. 13 is a logical flow diagram of an exemplary online cash register 
payment process 1300. The process 1300 begins with step 1310, in which the 
5 seller 130 agrees to sell goods to the buyer 110 for a specified price. This 
agreement is arrived at through the transaction facilitator 230. 

In step 1320, the payment enabler 240 assigns a unique reference number 
to the transaction. This reference number enables the seller 130 to monitor the 
transaction using the backroom capabilities of the personal merchant account. 

10 The seller 130 can also use this reference number to refer to the transaction 
when contacting the intermediary 120 to discuss the transaction, such as during 
fraud investigations and chargebacks. 

In step 1330, the payment enabler 240 determines additional charges for 
the transaction. For example, the payment enabler 240 may calculate sales tax, 

15 shipping charges, and handling charges. In step 1340, the payment enabler 240 
displays the online cash register to the buyer 110. The online cash register 
shows the price of the goods, the additional charges, and the total price. The 
online cash register also offers the buyer 110 a choice of payment instrument 
types to use for paying the total price. 

20 In step 1350, the buyer 110 selects one of the payment instrument types 

offered by the online cash register. The buyer 110 then provides the online 
cash register with registration information for registering a payment 
instrument corresponding to the payment instrument type selected. In step 
1355, the buyer 110 sends the online cash register a command to pay the seller 

25 130. 

In response to the command of the buyer 110, in step 1360, the payment 
enabler 240 obtains an authorization for a transfer of money from the buyer 
through the payment instrument to a first intermediary bank account. The 
amount of money authorized covers the total price shown by the online cash 
30 register. In step 1370, the payment enabler 240 orders the transfer of money 
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from a second intermediary bank account through the disbursement instrument 
to the seller 130. The amount of this transfer covers the amount due to the 
seller 130. The process 1300 then ends in step 1380. 
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CLAIMS 

The invention claimed is: 

1. A computer-implementable method for providing a consumer-to- 
consumer payment service, comprising: 

5 receiving from a first remote computer a registration by a payor of a 

payment instrument; 

receiving from a second remote computer a registration by a payee of a 
disbursement instrument; 

receiving from the first remote computer a command from the payor to 
10 pay the payee an amount of money; 

obtaining an authorization for a transfer of the amount of money from 
the payor through the payment instrument to a first intermediary bank account; 
and 

ordering a transfer of the amount of money from a second intermediary 
15 bank account through the disbursement instrument to the payee. 

2. The method of claim 1, wherein obtaining the authorization for the 
transfer of the amount of money comprises passing a risk of nonpayment by the 
payor to a third party. 

20 

3. The method of claim 1, wherein the authorization for the transfer 
of the amount of money comprises an authorization for an additional amount of 
money to cover the cost of the consumer-to-consumer payment service. 

25 4. The method of claim 1, wherein the first intermediary bank 

account and the second intermediary bank account are identical. 

5. The method of claim 1, wherein the first intermediary bank 
account and the second intermediary bank account are owned by an entity 
30 running the consumer-to-consumer payment service. 
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6. The method of claim 1, wherein the payment instrument comprises 
a flash cash deposit. 

7. The method of claim 6, wherein receiving from the first remote 
5 computer the registration by the payor of the payment instrument further 

comprises: 

prearranging a cash deposit to be made by the payor in person at a 
deposit location; and 

receiving notification from a flash cash processor that the payor has 
10 completed the deposit. 

8 . The method of claim 1 , wherein the payment instrument comprises 
a credit card. 

15 9. The method of claim 8, wherein receiving from the first remote 

computer the registration by the payor of the payment instrument further 
comprises: 

receiving from the payor registration information comprising a name, 
address, card association, card number, and card expiration date; 
20 sending the registration information to a credit card processor; 

receiving a comparison of the address and an address of record for a 
holder of the credit card; and 

determining whether the comparison indicates a sufficiently close match 
between the address and the address of record for the holder of the credit card. 

25 
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10. The method of claim 8, wherein obtaining the authorization for the 
transfer of the amount of money comprises: 

requesting that a credit card processor charge the amount of money 
against the credit card and transfer the amount of money to the first 
5 intermediary bank account; and 

receiving a decision whether the charge is accepted based upon decision 
factors comprising a spending limit for the credit card, a current balance for 
the credit card, and the amount of money. 

10 11. The method of claim 1, wherein the payment instrument comprises 

an electronic fund transaction. 

12. The method of claim 11, wherein receiving from the first remote 
computer the registration by the payor of the payment instrument further 
15 comprises: 

receiving from the payor registration information comprising a name, a 
routing number for a bank account to be used in the electronic fund transaction, 
and an account number for the bank account; 

sending the registration information to an electronic fund transaction 
20 processor; and 

receiving a decision, based on a review of a negative history file, whether 
future electronic fund transaction requests will be accepted by the electronic 
fund transaction processor. 
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13. The method of claim 11, wherein obtaining the authorization for 
the transfer of the amount of money comprises: 

requesting that an electronic fund transaction processor debit a bank 
account of the payor and credit the first intermediary bank account using an 
5 automated clearing house; and 

receiving a decision whether the request is accepted based upon decision 
factors comprising a current balance for the bank account of the payor and the 
amount of money. 

10 14. The method of claim 1, wherein the payment instrument comprises 

a paper check. 

15. The method of claim 14, wherein receiving from the first remote 
computer the registration by the payor of the payment instrument comprises: 
15 prearranging a check deposit to be made by the payor through a paper 

check sent through a postal service; and 

receiving notification from a paper check processor that the paper check 
has cleared. 

20 16. The method of claim 1, wherein the disbursement instrument 

comprises an electronic fund transaction. 
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17. The method of claim 16, wherein receiving from the second 
remote computer the registration by the payee of the disbursement instrument 
further comprises: 

receiving from the payee registration information comprising a name, a 
routing number for a bank account to be used in the electronic fund transaction, 
and an account number for the bank account; 

sending the registration information to an electronic fund transaction 
processor; and 

receiving notification that the bank account to be used in the electronic 
fund transaction exists. 

18. The method of claim 1, wherein the disbursement instrument 
comprises a paper check. 

19. The method of claim 18, wherein receiving from the second 
remote computer the registration by the payee of the disbursement instrument 
further comprises: 

receiving from the payee an address to which the paper check should be 
mailed; and 

receiving from the second remote computer a registration by the payee of 
a credit card to help prevent fraud by the payee and to enable chargebacks. 

20. The method of claim 1, further comprising: 

receiving a request from the payor for information about prior 
transactions of the payor; and 

providing the payor with the information about the prior transactions. 
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21. The method of claim 1, further comprising: 

receiving a request from the payee for information about prior 
transactions of the payee; and 

providing the payee with the information about the prior transactions. 

22. A computer-readable medium having computer-executable 
instructions for performing the method of claim 1 . 

23. A computer system adapted to perform the method of claim 1. 
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24. A computer-implementable method for providing a consumer-to- 
consumer payment service, comprising: 

offering a first plurality of financial instrument types to a payor at a first 
remote computer; 

5 receiving from the first remote computer a registration by the payor of a 

payment instrument comprising one of the first plurality of financial instrument 
types; 

receiving from a second remote computer a registration by a payee of a 
disbursement instrument; 
10 receiving from the first remote computer a command from the payor to 

pay the payee an amount of money; 

obtaining an authorization for a transfer of the amount of money from 
the payor through the payment instrument to a first intermediary bank account; 
and 

15 ordering a transfer of the amount of money from a second intermediary 

bank account through the disbursement instrument to the payee. 

25. A computer-readable medium having computer-executable 
instructions for performing the method of claim 24. 

20 

26. A computer system adapted to perform the method of claim 24. 
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27. A computer-implementable method for providing a consumer-to- 
consumer payment service, comprising: 

offering a first plurality of financial instrument types to a payor at a first 
remote computer; 

5 receiving from the first remote computer a registration by the payor of a 

payment instrument comprising one of the first plurality of financial instrument 
types; 

offering a second plurality of financial instrument types to a payee at a 
second remote computer; 
10 receiving from the second remote computer a registration by the payee of 

a disbursement instrument comprising one of the second plurality of financial 
instrument types; 

receiving from the first remote computer a command from the payor to 
pay the payee an amount of money; 
15 obtaining an authorization for a transfer of the amount of money from 

the payor through the payment instrument to a first intermediary bank account; 
and 

ordering a transfer of the amount of money from a second intermediary 
bank account through the disbursement instrument to the payee. 

20 

28. The method of claim 27, wherein the first plurality of financial 
instrument types are selected from the group consisting of flash cash deposit, 
credit card, electronic fund transaction, virtual private payment account, and 
paper check. 

25 

29. The method of claim 27, wherein the second plurality of financial 
instrument types are selected from the group consisting of electronic fund 
transaction, virtual private payment account, and paper check. 
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30. A computer-readable medium having computer-executable 
instructions for performing the method of claim 27. 

31 . A computer system adapted to perform the method of claim 27. 
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METHOD AND SYSTEM FOR FACILITATING FINANCIAL 
TRANSACTIONS BETWEEN CONSUMERS OVER THE 
INTERNET 

5 ABSTRACT OF THE DISCLOSURE 

A method for enabling two individual consumers to complete a 
transaction that includes payment from one consumer (the payor, or buyer) to 

10 another consumer (the payee, or seller). An intermediary typically operates the 
service over a computer network of nodes, such as the Internet. The buyer has 
the convenience of paying through a variety of different payment instruments. 
Likewise, the seller has the convenience of receiving payment through a variety 
of different disbursement instruments. For a fee, the intermediary collects the 

15 payment from the buyer and pays the seller. Although the intermediary may 
receive payment from the buyer before the intermediary transfers the payment 
to the seller, the intermediary may choose to pay the seller before receiving 
payment from the buyer. In this case, the intermediary assumes the risk of 
nonpayment by the buyer. Alternatively, the intermediary may pay a third 

20 party that specializes in processing transactions for the payment instrument 
chosen by the buyer to assume the risk of nonpayment by the buyer. In this 
case, the intermediary receives a promise of payment from the third party 
before the intermediary pays the seller. Such a promise of payment from the 
third party is referred to as an authorization. 

25 
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■ ILLUSTRATION 100B OF THE 
TRANSFER OF MONEY IN A 
CONSUMER-TO-CONSUMER 
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THE TRANSACTION FACILITATOR RESULTS IN AN 

AGREED UPON TRANSACTION 
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SELLER SELECTS A DISBURSEMENT INSTRUMENT THAT 
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INSTRUCTS PAYMENT ENABLER TO DISBURSE MONEY 
DUE FROM BUYER THROUGH SELECTED INSTRUMENT 
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FIG. 3 
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FROM STEP 310 OF FIG 
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— REGISTRATION OF A 
FLASH CASH DEPOSIT 
AS A PAYMENT INSTRUMENT 
(ROUTINE 320 ON FIG. 3) 



PAYMENT ENABLER PRESENTS BUYER WITH A 
GRAPHICAL USER INTERFACE ENABLING THE BUYER TO 
ENTER IDENTIFICATION INFORMATION AND A DEPOSIT 
AMOUNT 



BUYER ENTERS THE REQUESTED INFORMATION 
THROUGH THE GRAPHICAL USER INTERFACE 



PAYMENT ENABLER CREATES A REGISTRATION 
RECORD FOR THE FLASH CASH DEPOSIT IN A 
REGISTRATION DATABASE STORED BY THE PAYMENT 
ENABLER 



PAYMENT ENABLER STORES A FLAG IN THE 
REGISTRATION RECORD TO INDICATE THAT THE BUYER 
HAS NOT YET MADE THE DEPOSIT 



PAYMENT ENABLER PROVIDES THE FLASH CASH 
PROCESSOR WITH THE BUYER IDENTIFICATION 
INFORMATION AND DEPOSIT AMOUNT 



BUYER PHYSICALLY GOES TO A DEPOSIT LOCATION 
REGISTERED WITH THE FLASH CASH PROCESSOR AND 
DEPOSITS CASH IN THE AMOUNT PREVIOUSLY 

SPECIFIED . 



DEPOSIT LOCATION ELECTRONICALLY NOTIFIES THE 
FLASH CASH PROCESSOR THAT THE BUYER HAS 
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THE FLASH CASH PROCESSOR NOTIFIES THE PAYMENT 
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PAYMENT ENABLER UPDATES THE FLAG IN THE 
REGISTRATION RECORD TO INDICATE THAT BUYER HAS 
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FIG. 4A 
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— REGISTRATION OF A 
CREDIT CARD 
AS A PAYMENT INSTRUMENT 
(ROUTINE 320 ON FIG. 3) - 
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CARD NUMBER, AND CARD EXPIRATION DATE THROUGH 
THE GRAPHICAL USER INTERFACE 



PAYMENT ENABLER PROVIDES INFORMATION ENTERED 
BY BUYER TO THE CREDIT CARD TRANSACTION 
PROCESSOR FOR REGISTRATION PROCESSING 



CREDIT CARD TRANSACTION PROCESSOR COMPARES 
THE ADDRESS PROVIDED BY THE PAYMENT ENABLER 
TO THE ADDRESS OF RECORD FOR THE CREDIT CARD 
HOLDER 



CREDIT CARD TRANSACTION PROCESSOR SENDS THE 
PAYMENT ENABLER A SCORE INDICATING THE DEGREE 
TO WHICH THE ADDRESS PROVIDED BY THE PAYMENT 
ENABLER AND THE ADDRESS OF RECORD MATCH 
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A PAYMENT INSTRUMENT VIA 
ELECTRONIC FUND TRANSACTIONS 
(ROUTINE 320 ON FIG. 3) 



PAYMENT ENABLER PRESENTS BUYER WITH A 
GRAPHICAL USER INTERFACE ENABLING THE BUYER TO 
ENTER BANKACCOUNT REGISTRATION INFORMATION 



BUYER ENTERS NAME, ROUTING NUMBER, AND 
ACCOUNT NUMBER THROUGH THE GRAPHICAL USER 
INTERFACE 



PAYMENT ENABLER PROVIDES INFORMATION ENTERED 
BY BUYER TO THE ELECTRONIC FUND TRANSACTION 
PROCESSOR FOR REGISTRATION PROCESSING 



ELECTRONIC FUND TRANSACTION PROCESSOR 
REVIEWS NEGATIVE HISTORY DATABASE TO 
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ACCOUNT 




ELECTRONIC FUND TRANSACTION PROCESSOR 
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BUYER ENTERS THE REQUESTED INFORMATION 
THROUGH THE GRAPHICAL USER INTERFACE 



PAYMENT ENABLER CREATES A REGISTRATION 
RECORD FOR THE CHECK DEPOSIT IN A REGISTRATION 
DATABASE STORED BY THE PAYMENT ENABLER 



PAYMENT ENABLER STORES A FLAG IN THE 
REGISTRATION RECORD TO INDICATE THAT THE BUYER 
HAS NOT YET MADE THE CHECK DEPOSIT 



PAYMENT ENABLER PROVIDES THE CHECK PROCESSOR 
WITH THE BUYER IDENTIFICATION INFORMATION AND 
CHECK DEPOSfT AMOUNT 



BUYER SENDS A PHYSICAL CHECK TO AN ADDRESS 
SPECIFIED BY THE CHECK PROCESSOR 
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SELLER ENTERS ACCOUNT PROVIDER AND ACCOUNT 
NUMBER THROUGH THE GRAPHICAL USER INTERFACE 
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PAYMENT ENABLER CREATES A REGISTRATION 
RECORD, IN A REGISTRATION DATABASE STORED BY 
THE PAYMENT ENABLER, INDICATING THAT THE 
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— REGISTRATION FOR 
RECEIVING A MAILED CHECK AS 
THE DISBURSEMENT INSTRUMENT 
(ROUTINE 330 ON FIG. 3) - 



PAYMENT ENABLER PRESENTS SELLER WITH A 
GRAPHICAL USER INTERFACE ENABLING SELLER TO 
ENTER REGISTRATION INFORMATION FOR RECEIVING 
DISBURSEMENTS THROUGH A MAILED CHECK 



THROUGH THE GRAPHICAL USER INTERFACE, SELLER 
ENTERS HIS NAME AND ADDRESS TO WHICH THE 
SELLER WANTS THE CHECK PROCESSOR TO MAIL 
DISBURSEMENT CHECKS 



AS REQUIRED BY THE GRAPHICAL USER INTERFACE 
FOR FRAUD PROTECTION AND CHARGEBACK 
PURPOSES, SELLER ENTERS CREDIT CARD 
INFORMATION (CARD ASSOCIATION, CARD NUMBER, 
AND CARD EXPIRATION DATE) 



PAYMENT ENABLER PROVIDES INFORMATION ENTERED 
BY SELLER TO THE CREDIT CARD TRANSACTION 
PROCESSOR FOR REGISTRATION PROCESSING 



CREDIT CARD TRANSACTION PROCESSOR COMPARES 
THE ADDRESS PROVIDED BY THE PAYMENT ENABLER 
TO THE ADDRESS OF RECORD FOR THE CREDIT CARD 
HOLDER 



CREDIT CARD TRANSACTION PROCESSOR SENDS THE 
PAYMENT ENABLER A SCORE INDICATING THE DEGREE 
TO WHICH THE ADDRESS PROVIDED BY THE PAYMENT 
ENABLER AND THE ADDRESS OF RECORD MATCH 
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PAYMENT ENABLER CREATES A REGISTRATION 
RECORD, IN A REGISTRATION DATABASE STORED BY 
THE PAYMENT ENABLER, THAT INDICATES SELLER CAN 
RECEIVE MAILED CHECK DISBURSEMENTS AND THAT 
INCLUDES THE CREDIT CARD INFORMATION 
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BY THE PAYMENT ENABLER 
(ROUTINE 360 ON 
FIGS. 3, 9, 10, AND 11) 
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ACCEPTABLE GOODS 
TO THE BUYER 
(ROUTINE 640 ON FIG. 6) 



PAYMENT ENABLER NOTIFIES SELLER THAT PAYMENT 
IS GUARANTEED UPON RECEIPT AND ACCEPTANCE OF 
THE GOODS BY THE BUYER 



PAYMENT ENABLER INSTRUCTS SELLER TO SHIP THE 
GOODS TO THE BUYER VIA AN APPROVED SHIPPING 
SERVICE 



SELLER SHIPS THE GOODS 
SHIPPING SERVICE THAT PR 
TRACKING NUMBER FOR TF 
GO( 


> THROUGH AN APPROVED 
OVIDES THE SELLER WITH A 
RACKING DELIVERY OF THE 
DDS 




r 740 


SELLER NOTIFIES PAYMENT ENABLER OF THE 
TRACKING NUMBER, ALLOWING BOTH SELLER AND 
BUYER TO TRACK DELIVERY OF THE GOODS THROUGH 
A GRAPHICAL USER INTERFACE 




r 750 


PAYMENT ENABLER PERIODICALLY QUERIES THE 
SHIPPING SERVICE TRACKING DATABASE UNTIL THE 
TRACKING DATABASE INDICATES A DATE OF DELIVERY 




770 



ACCEPTABLE 
GOODS HAVE 
NOT BEEN 
DELIVERED 



ACCEPTABLE GOODS HAVE BEEN DELIVERED 
(BUYER NOTFIFED PAYMENT ENABLER OF ACCEPTANCE 
THROUGH A GRAPHICAL USER INTERFACE OR FAILED 
TO REJECT THE GOODS WITHIN THE PREDETERMINED 
TIME PERIOD) 



RETURN 
GO TO STEP 650 OF FIG. 



-~^79 

5,61^ 



FIG. 7 



~ REFUND MONEY 
TO THE BUYER 
(ROUTINE 660 ON FIG. 6) 



BEGIN 
FROM STEP 650 OF FIG. 



7> 



PAYMENT ENABLER NOTIFIES SELLER THAT BUYER HAS 
REJECTED THE GOODS 



PAYMENT ENABLER INSTRUCTS BUYER TO SHIP THE 
GOODS BACK TO THE SELLER VIA AN APPROVED 
SHIPPING SERVICE 



830 



BUYER SHIPS THE GOODS THROUGH AN APPROVED 
SHIPPING SERVICE THAT PROVIDES THE BUYER WITH A 
TRACKING NUMBER FOR TRACKING DELIVERY OF THE 
GOODS 



BUYER NOTIFIES PAYMENT ENABLER OF THE TRACKING 

NUMBER, ALLOWING BOTH SELLER AND BUYER TO 
TRACK DELIVERY OF THE RETURNED GOODS THROUGH 
A GRAPHICAL USER INTERFACE 



_S50 



PAYMENT ENABLER PERIODICALLY QUERIES THE 
SHIPPING SERVICE TRACKING DATABASE UNTIL THE 
TRACKING DATABASE INDICATES A DATE OF DELIVERY 



SELLER NOTIFIES 
"PAYMENT ENABLER OF REJECTION^ 
£F THE RETURNED GOODS WITHIN A PREDETERMINE^ 
AMOUNT OF TIME OF 
DELIVERY DATE? 





PAYMENT 




ENABLER 


YES 


CONTROLS 


• ► 


MONEY UNTIL 




DISPUTE IS 




RESOLVED 



PAYMENT ENABLER REFUNDS MONEY TO THE BUYER, 
LESS THE CHARGE FOR THE CONSUMER TO 
CONSUMER PAYMENT SERVICE 



RETURN 
'GO TO STEP 680 OF FIG. 



— - — 
6)^ 



FIG. 8 



- AUCTION PROCESS 900 INCLUDING 
STATIC REGISTRATION OF 
BUYER AND SELLER WITH THE 
PAYMENT ENABLER 



SELLER AND BUYER SEPARATELY REGISTER FOR 
PARTICIPATION IN A WEB-BASED AUCTION SITE 
(TRANSACTION FACILITATOR) AND EACH RECEIVE A 
UNIQUE USER ID FROM THE AUCTION SITE 



BUYER REGISTERS WITH PAYMENT ENABLER THROUGH 
AN IDENTICALLY BRANDED WEB PAGE PROVIDED BY THE 
PAYMENT ENABLER, WHICH IS PASSED THE BUYER USER 
ID FOR USE AS THE REGISTRATION RECORD KEY 



SELLER REGISTERS WlTH PAYMENT ENABLER THROUGH 
AN IDENTICALLY BRANDED WEB PAGE PROVIDED BY THE 
PAYMENT ENABLER, WHICH IS PASSED THE SELLER USER 
ID FOR USE AS THE REGISTRATION RECORD KEY 



BUYER WINS A BIDDING PROCESS FOR SELLER'S ITEM 
(GOODS), AND THE AUCTION SITE ASSIGNS A UNIQUE 
TRANSACTION ID FOR USE AS A KEY TO A RECORD 

STORING THE TRANSACTION DETAILS 



BUYER NOTIFIES AUCTION SITE OF BUYER'S DESIRE TO 
PAY SELLER THROUGH THE SERVICES OF THE PAYMENT 
ENABLER 



AUCTION SITE PROVIDES TRANSACTION DETAILS 
(INCLUDING THE TRANSACTION ID) TO THE PAYMENT 
ENABLER, WHICH STORES THE INFORMATION IN A 

DATABASE 



THROUGH A WEB PAGE OF THE PAYMENT ENABLER, 
SELLER SELECTS DISBURSEMENT INSTRUMENT AND 
CREATES ELECTRONIC INVOICE FOR THE TRANSACTION 
(INVOICE MAY INCLUDE BID PRICE, SHIPPING CHARGES, 
HANDLING CHARGES. AND TOTAL PRICE) 



BUYER REVIEWS INVOICE THROUGH A PAYMENT ENABLER 
WEB PAGE 

(THERE MAY BE AN OPPORTUNITY TO NEGOTIATE THE 
TERMS STATED IN THE INVOICE) 



BUYER SELECTS A REGISTERED PAYMENT INSTRUMENT 
AND INSTRUCTS PAYMENT ENABLER TO PAY SELLER 

USING THE SELECTED INSTRUMENT 



PAYMENT ENABLER ENSURES COMPLETION 
OF THE TRANSACTION BETWEEN BUYER 
AND SELLER 



It- AUCTION PROCESS 1000 INCLUDING 

DYNAMIC REGISTRATION OF 
BUYER WITH THE 
PAYMENT ENABLER 



SELLER AND BUYER SEPARATELY REGISTER FOR 
PARTICIPATION IN A WEB-BASED AUCTION SITE 
(TRANSACTION FACILITATOR) AND EACH RECEIVE A 
UNIQUE USER ID FROM THE AUCTION SITE 



SELLER REGISTERS WITH PAYMENT ENABLER THROUGH 
AN IDENTICALLY BRANDED WEB PAGE PROVIDED BY THE 
PAYMENT ENABLER, WHICH IS PASSED THE SELLER USER 
ID FOR USE AS THE REGISTRATION RECORD KEY 



BUYER WINS A BIDDING PROCESS FOR SELLER'S ITEM 
(GOODS), AND THE AUCTION SITE ASSIGNS A UNIQUE 
TRANSACTION ID FOR USE AS A KEY TO A RECORD 
STORING THE TRANSACTION DETAILS 



BUYER NOTIFIES AUCTION SITE OF BUYER'S DESIRE TO 
PAY SELLER THROUGH THE PAYMENT ENABLER 



AUCTION SITE REDIRECTS BUYER'S BROWSER TO THE 
REGISTRATION PAGE OF THE PAYMENT ENABLER 



BUYER REGISTERS WITH PAYMENT ENABLER THROUGH 
AN IDENTICALLY BRANDED WEB PAGE PROVIDED BY THE 
PAYMENT ENABLER, WHICH IS PASSED THE BUYER USER 
ID FOR USE AS THE REGISTRATION RECORD KEY 



AUCTION SITE PROVIDES TRANSACTION DETAILS 
(INCLUDING THE TRANSACTION ID) TO THE PAYMENT 
ENABLER, WHICH STORES THE INFORMATION IN A 
DATABASE 



THROUGH A WEB PAGE OF THE PAYMENT ENABLER, 
SELLER SELECTS DISBURSEMENT INSTRUMENT AND 
CREATES ELECTRONIC INVOICE FOR THE TRANSACTION 
(INVOICE MAY INCLUDE BID PRICE, SHIPPING CHARGES, 
HANDLING CHARGES, AND TOTAL PRICE) 



BUYER REVIEWS INVOICE THROUGH A PAYMENT ENABLER 
WEB PAGE 

(THERE MAY BE AN OPPORTUNITY TO NEGOTIATE THE 
TERMS STATED IN THE INVOICE) 



BUYER SELECTS A REGISTERED PAYMENT INSTRUMENT 
AND INSTRUCTS PAYMENT ENABLER TO PAY SELLER 
USING THE SELECTED INSTRUMENT 

PAYMENT ENABLER ENSURES COMPLETION 
OF THE TRANSACTION BETWEEN BUYER 
AND SELLER 



FIG. 10 



{£■ AUCTION PROCESS 1100 INCLUDING 

> DYNAMIC REGISTRATION OF 

SELLER WITH THE 
PAYMENT ENABLER 



SELLER AND BUYER SEPARATELY REGISTER FOR 
PARTICIPATION IN A WEB-BASED AUCTION SITE 
(TRANSACTION FACILITATOR) AND EACH RECEIVE A 
UNIQUE USER ID FROM THE AUCTION SITE 



BUYER REGISTERS WITH PAYMENT ENABLER THROUGH 
AN IDENTICALLY BRANDED WEB PAGE PROVIDED BY THE 
PAYMENT ENABLER, WHICH IS PASSED THE BUYER USER 
ID FOR USE AS THE REGISTRATION RECORD KEY 



BUYER WINS A BIDDING PROCESS FOR SELLER'S ITEM 
(GOODS), AND THE AUCTION SITE ASSIGNS A UNIQUE 
TRANSACTION ID FOR USE AS A KEY TO A RECORD 
STORING THE TRANSACTION DETAILS 



BUYER NOTIFIES AUCTION SITE OF BUYER'S DESIRE TO 
PAY SELLER THROUGH THE PAYMENT ENABLER 



AUCTION SITE ENABLES BUYER TO REQUEST THAT 
SELLER REGISTER WITH THE PAYMENT ENABLER 



SELLER REGISTERS WITH PAYMENT ENABLER THROUGH 
AN IDENTICALLY BRANDED WEB PAGE PROVIDED BY THE 
PAYMENT ENABLER, WHICH IS PASSED THE SELLER USER 
ID FOR USE AS THE REGISTRATION RECORD KEY 



AUCTION SITE PROVIDES TRANSACTION DETAILS 
(INCLUDING THE TRANSACTION ID) TO THE PAYMENT 
ENABLER, WHICH STORES THE INFORMATION IN A 

DATABASE 

i 

THROUGH A WEB PAGE OF THE PAYMENT ENABLER, 
SELLER SELECTS DISBURSEMENT INSTRUMENT AND 
CREATES ELECTRONIC INVOICE FOR THE TRANSACTION 
(INVOICE MAY INCLUDE BID PRICE, SHIPPING CHARGES, 
HANDLING CHARGES, AND TOTAL PRICE) 



BUYER REVIEWS INVOICE THROUGH A PAYMENT ENABLER 
WEB PAGE 

(THERE MAY BE AN OPPORTUNITY TO NEGOTIATE THE 
TERMS STATED IN THE INVOICE) 



BUYER SELECTS A REGISTERED PAYMENT INSTRUMENT 
AND INSTRUCTS PAYMENT ENABLER TO PAY SELLER 
USING THE SELECTED INSTRUMENT 



PAYMENT ENABLER ENSURES COMPLETION 
OF THE TRANSACTION BETWEEN BUYER 
AND SELLER 



ONLINE CASH REGISTER 
CREATION PROCESS 1200 



THE SELLER PROVIDES THE PAYMENT ENABLER WITH 
IDENTIFICATION INFORMATION AND REQUESTS A 
PERSONAL MERCHANT ACCOUNT 



THE PAYMENT ENABLER CREATES THE PERSONAL 
MERCHANT ACCOUNT 



THE SELLER REGISTERS A DISBURSEMENT INSTRUMENT 
WITH THE PAYMENT ENABLER FOR RECEIVING PAYMENTS 
MADE TO THE SELLER THROUGH AN ONLINE CASH 
REGISTER 



THE SELLER SELECTS THE PAYMENT INSTRUMENT TYPES 
THE SELLER WISHES TO OFFER THROUGH THE ONLINE 
CASH REGISTER 



FOR EACH PAYMENT INSTRUMENT TYPE SELECTED BY 
THE SELLER, THE PAYMENT ENABLER REQUESTS AND 
RECEIVES UNDERWRITING ASSESSMENT INFORMATION 



FOR EACH PAYMENT INSTRUMENT TYPE THE PAYMENT 
ENABLER PERFORMS AN UNDERWRITING ASSESSMENT 
TO DETERMINE WHETHER THE SELLER CAN OFFER THAT 
INSTRUMENT TYPE IN THE ONLINE CASH REGISTER 




SELLER DENIED 
► AN ONLINE 
CASH REGISTER 



THE PAYMENT ENABLER PERMITS THE SELLER TO DEFINE 
ADDITIONAL CHARGES TO BE ADDED TO THE SALE PRICE 
OF ANY GOODS, SUCH AS SALES TAX, SHIPPING 
CHARGES, AND HANDLING CHARGES 



PAYMENT ENABLER WILL PROVIDE THE ONLINE CASH 
REGISTER TO EACH BUYER WHO AGREES TO BUY GOODS 
FROM THE SELLER, ENABLING THE BUYER TO PAY 
THROUGH ANY APPROVED PAYMENT METHOD 



FIG. 12 



ONLINE CASH REGISTER 
PAYMENT PROCESS 1300 







THE SELLER AGREES TO SELL GOODS TO THE BUYER FOR 
A SPECIFIED PRICE 
(AGREEMENT ARRIVED AT THROUGH THE TRANSACTION 
FACILITATOR) 




r 


THE PAYMENT ENABLER ASSIGNS A UNIQUE REFERENCE 
NUMBER TO THE TRANSACTION SO THE SELLER CAN 
MONITOR THE TRANSACTION USING BACKROOM 
CAPABILITIES OF THE PERSONAL MERCHANT ACCOUNT 




r 


THE PAYMENT ENABLER DETERMINES ADDITIONAL 
CHARGES FOR THE TRANSACTION 




r 


THE PAYMENT ENABLER DISPLAYS THE ONLINE CASH 
REGISTER TO THE BUYER. THE ONLINE CASH REGISTER 
SHOWS THE PRICE OF THE GOODS, THE ADDITIONAL 
CHARGES, AND THE TOTAL PRICE 


1 


r 


THE BUYER SELECTS ONE OF THE PAYMENT INSTRUMENT 
TYPES OFFERED BY THE ONLINE CASH REGISTER AND 
PROVIDES REGISTRATION INFORMATION FOR 
REGISTERING A CORRESPONDING PAYMENT INSTRUMENT 




r 


THE BUYER SENDS THE ONLINE CASH REGISTER A 
COMMAND TO PAY THE SELLER 




r 


THE PAYMENT ENABLER OBTAINS AN AUTHORIZATION 
FOR A TRANSFER OF MONEY (TO COVER THE TOTAL 
PRICE) FROM THE BUYER THROUGH THE PAYMENT 
INSTRUMENT TO A FIRST INTERMEDIARY BANK ACCOUNT 




r 


THE PAYMENT ENABLER ORDERS THE TRANSFER OF 
MONEY FROM A SECOND INTERMEDIARY BANK ACOUNT 
THROUGH THE DISBURSEMENT INSTRUMENT TO THE 
SELLER 




r irwn 



FIG. 13 



